pan-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Pan-users] Re: Bug squashed


From: Duncan
Subject: [Pan-users] Re: Bug squashed
Date: Thu, 21 Jan 2010 11:20:21 +0000 (UTC)
User-agent: Pan/0.133 (House of Butterflies)

SciFi posted on Thu, 21 Jan 2010 07:22:12 +0000 as excerpted:

> I do not see how we can have two different versions of gmime installed
> on the same system.  Here is how it looks to us (with 2.2.23):

gmime is what Gentoo calls a "slotted" library.  The 2.2 "slot" is 
separate from the 2.4 "slot", such that both can be installed at the same 
time, without conflict, even with package building -- and Gentoo users do 
a *LOT* of package building! =:^)

Now for "leaf" packages, generally executables, Gentoo can and sometimes 
does "slot" things that upstream hasn't slotted.  However, for libraries, 
that gets messy pretty fast, especially when binaries and other libraries 
are being built against the libraries and they need to continue working, 
so the typical different paths and switch-out type arrangements doesn't 
work so well.  Thus, libraries only tend to be slotted when upstream 
designs the packages to be used together.  Thus, it's a reasonably sure 
thing that glib-2.2 and glib-2.4 are /designed/ to not interfere with 
each other, when both installed on the same system.

> $ cat libgmime-2.0.la

I don't know how much of the following about *.la files applies to you on 
OSX, but perhaps someone will get something useful from it.

I have no idea how close the OSX/BSD libc linker is to the GNU/Linux 
glibc linker, or whether it's perhaps part of the ELF spec and whether 
OSX/BSD uses that, but FWIW, on Linux, *.la files are outdated for normal 
use, and the files often cause more trouble than they solve on a normal 
dynamically linked system (they're used for static linking only on 
Gnu/Linux), so Gentoo is working on phasing them out, for the most part.

One of the problems is *.la files that "link" to other *.la files, 
instead of to the libraries directly.  This causes all sorts of issues 
when lower level library dependencies are rebuilt.  Since *.la files 
don't tend to be needed except for static builds and a modern glibc based 
Linux system is normally almost entirely dynamic linked, ultimately, 
getting rid of these *.la files is the way to go.  However, when *.la 
files link to other *.la files, if they're not removed in the right 
order, things can break pretty badly.

As a result there's a tool called lafilefixer that Gentoo uses to scan 
thru all the *.la files, find links to other *.la files, and rewrite the 
links so they point to the libraries directly.  That way, the order in 
which the *.la files are removed, package by package, is no longer so 
critical, and the tool prevents a *LOT* of needless reverse-dependency 
rebuilding, with a few simple *.la file line-edits! =:^)

At the end of my routine updetes (done once or twice a week, normally) 
I'm in the habit of running a few cleanup scripts, including one that 
checks to see if there's any now unneeded former dependencies I can 
unmerge, and another that does a reverse-dependency scan and rebuild as 
necessary.  Between the --as-needed linker flag, however, and the 
lafilefixer script, which I now run immediately before the reverse-
dependency rebuilder, I have FAR less rebuilds to do than might be 
expected. =:^)

> Please remember I build everything old-fashionedly by my own hands.  ;)

I certainly appreciate that!

Of course, Gentoo does rebuilds too, makes for far more detailed 
customization than possible in a binary distribution, but they've 
automated the process quite a bit, so it's not as bad as it might be 
otherwise.  FWIW, there's what's called the Gentoo/prefix project, that 
allows use of the Gentoo build system on OSX among others, by installing 
to a "prefix" dir, instead of to root.  If you're interested...

Not that you are of course, but it just seems like building it from 
sources shouldn't have to be done /entirely/ by hand, and Gentoo /does/ 
have a pretty decent system of automating the process -- while still 
allowing the user control of what they want to control, thru customized 
ebuild scripts if nothing else.  I do enough ebuild customization and 
other "advanced" usage "I otta know!" =:^)

> When installing a newer gmime build, some of the pointers etc will
> change, then some apps gripe about the lack of expected things etc,
> y'know.
> 
> I was trying to put on gmime-2.4.3 at one point. Got into too much
> trouble afterwards. That's when I stopped and re-installed 2.2.23, while
> I began hollering in the related bug-report since Pan officially still
> wasn't fixed fully at that time.

Really, they /should/ be installable basically side-by-side.  Gentoo 
ebuilds are basically bash scripts.  You could go check them out and see 
how Gentoo does it if you'd like.  That could give you a few hints as to 
what you need to do, if anything, to have them side-by-side done 
manually, as well.

(FWIW, here I build binpkgs archives when I build stuff, part of that 
automation and choice mentioned above, and do occasionally browse 
versions of a binpkg side by side, just to see what's changed.  The 
portage check for file collisions is automated, of course, but can be 
overruled if necessary.)

-- 
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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]