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 mailing list Pan-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/pan-users
