Re: [Pan-users] 'Old' Pan (pan-0.14.2.91-4mdk.i586.rpm): No longer installs (Mageia)

[Duncan]

Maurice Batey posted on Fri, 14 Dec 2012 18:00:26 +0000 as excerpted:

> Having used 'old' Pan for many years (and having tried 'new' Pan a while
> ago), I have managed to install it on Mandriva 2010.2 and also Mageia-1
> and -2.
> 
> But it won't install on Mageia-3 (Alpha2):
> 
>   "...due to unsatisfied libpcre.so.0"
> 
> and (using a slightly different Pan RPM):
>   "..due to unsatisfied libXft.so.1"
> 
> Anyone here succeeded on Mageia-3-Alpha/Beta, by any chance?

The "lucky" hit on a google for libpcre.so.0 returns...

http://forums.freebsd.org/showthread.php?t=29858

... which seems to indicate that (at least on freebsd) between 
libpcre-8.21 and libpcre-8.30, the so bumped from libpcre.so.0 to 
libpcre.so.1 .

The "correct" fix is to rebuild everything depending on libpcre that was 
built against the old version.  On gentoo, there's a script (called 
revdep-rebuild) that automates finding such issues and doing the 
rebuilds, that experienced gentooers generally run routinely after every 
major update.

However, such rebuilds can quickly get into "rpm dependency hell" on 
binary-based distros, and there's a quick hack that OFTEN works, and 
seemed to work as a temp fix in fbsd (also source-based) thread mentioned 
above: do a symlink, libpcre.so.0 -> libpcre.so.1 .

Of course that very possibly won't solve the package dependency issue 
(depending on how the dep is specified, as a specific file dep or a 
package version dep) as rpm won't know, but if that's the only missing 
dep, you should be able to do a --nodeps (or whatever) install, and it 
MIGHT "just work".

But the symlink thing is just a hack that may or may not work, and may 
break with other updates especially if you had to do the nodeps thing as 
well, since you're bypassing rpm to do it.  The "correct" fix is as I 
said, rebuild pan against the newer library.  But to do that you'd likely 
have to install other deps, at least -dev(el) packages for various 
libraries, and as stale as the old-pan code is, you may run into other 
issues as well.  So I'd suggest /trying/ the hack.

I didn't look into it, but it's possible the libXft.so.1 issue can be 
solved the same way, if for some reason the symlink trick won't work for 
pcre and you need to try the other rpm.

Meanwhile, sysadmin suggestion.  Keep a file somewhere listing such hacks 
and the reasons for them, along with any deps you pull in for packages 
you build yourself, etc.  That allows you to undo or duplicate the hacks 
at a future time, if necessary.

And of course, stale code does tend to break against modern systems 
eventually.  So at some point you'll need to find a different solution.  
But this isn't necessarily that point, and I'm sure you knew that already.

As for new-pan not satifying your needs, Heinrich has integrated a number 
of updates over the last couple years, including a score-based automated 
"actions" feature that finally replaces old-pan's "rules" feature for 
automatically downloading/marking-read/deleting selected posts.  That was 
the last major old-pan feature missing from new-pan, and new-pan now 
natively supports binary attachments and secure connections as well, 
features that had been on many pan user's wishlist for over a /decade/, 
so you /may/ find it works for you now.  It's not identical, but with 
actions replacing the last truly missing feature from old-pan and with 
native binary uploading and secure connections now, you /may/ find the 
change worth the retraining.

The one "accidental feature" of old-pan that I'm aware of that's still 
missing, that simply can't be done in the same way (but there's a 
different way that works) in new pan due to its transparent multi-server 
handling feature, is old-pan's ability to categorize groups by simply 
creating different "servers" for them, even if they all pointed to the 
same physical server.  New-pan has a single (alphabetical) listing of all 
subscribed groups, and can't categorize the same way because multiple 
servers are handled transparently, with the group lists combined.

However, it's possible to work around that with a different new-pan 
feature, just as the old-pan method of catagorization using multiple 
servers was a workaround for the single list per server, no group 
categories, issue.  It's just a different workaround.  In new-pan, the 
workaround is to use new-pan's ability to set its data dir via the 
PAN_HOME environmental variable.  You simply setup multiple pan 
configurations, each in its own dir, and use a wrapper script to set the 
environmental variable appropriately, before starting pan.  I've been 
doing that with "new-pan" here, for years, now. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman