[Top][All Lists]
[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
- [Pan-users] Bug squashed, K. Haley, 2010/01/07
- [Pan-users] Re: Bug squashed, SciFi, 2010/01/08
- Re: [Pan-users] Re: Bug squashed, K. Haley, 2010/01/08
- [Pan-users] Re: Bug squashed, SciFi, 2010/01/15
- [Pan-users] Re: Bug squashed, SciFi, 2010/01/15
- Re: [Pan-users] Re: Bug squashed, K. Haley, 2010/01/16
- [Pan-users] Re: Bug squashed, SciFi, 2010/01/21
- [Pan-users] Re: Bug squashed,
Duncan <=
- Re: [Pan-users] Re: Bug squashed, K. Haley, 2010/01/22
- [Pan-users] Re: Bug squashed, Duncan, 2010/01/22
- Re: [Pan-users] Re: Bug squashed, K. Haley, 2010/01/23
- [Pan-users] Re: Bug squashed, Duncan, 2010/01/24