This is a problem common to all non-GNU operating systems, as ldconfig is used with -n -N params that makes sense only on GNU/Linux (or maybe GNU/Hurd too?). I don't really know what ldconfig is supposed to do in that case, but we should find a solution other than use it to unbreak G/FBSD.
i'm pretty sure that ldconfig should just be punted from preplib
That was my understanding as well. I've been doing that with other packages, so let me know if that isn't true.
Portage devs, ping :)
Sigh, ping.
Don't know what preplib's purpose is, nor is it clear to me from reading it so I have no idea on ways to fix this bug, but... (big breath) pong!
Mike, you that know what that is, can you take a look? :P
i'll look into just punting preplib and preplib.so they serve no real purpose as no package should really be installing libraries such that the ABI symlinks *need* to be updated inside of $D
preplib.so is gone, nothing in the tree uses it
Hm I'm wondering if we can get a "generic" preplib replacement for other systems where it just make sure that there's a link to the soname of the library, by using scanelf -Sq .
that wouldnt really work for Darwin ... really i'd just like to see the thing die
Remaining packages using preplib: media-video/ffmpeg/ffmpeg-0.4.9_p20050226-r3.ebuild:145: preplib /usr media-video/ffmpeg/ffmpeg-0.4.9_p20051216.ebuild:176: preplib /usr net-misc/nx-x11/nx-x11-1.4.0-r3.ebuild:100: preplib /usr/NX net-misc/nx-x11/nx-x11-1.4.0-r4.ebuild:103: preplib /usr/NX net-misc/nxcomp/nxcomp-1.3.2-r1.ebuild:33: preplib /usr/NX net-misc/nxcomp/nxcomp-1.5.0-r1.ebuild:45: preplib /usr/NX/lib sys-libs/lib-compat-loki/lib-compat-loki-0.1.ebuild:39: preplib /usr sys-libs/lib-compat-loki/lib-compat-loki-0.2.ebuild:42: preplib /usr sys-libs/lib-compat/lib-compat-1.4.1.ebuild:41: preplib /usr sys-libs/lib-compat/lib-compat-1.4.ebuild:41: preplib /usr
lib-compat-loki done
net-misc/nx-x11/nx-x11-1.4.* removed (they were not modular X-aware) net-misc/nxcomp should be going away soon (superseeded by net-misc/nx)
net-misc/nxcomp removed from tree, all done for NX
Remaining packages: media-video/ffmpeg/ffmpeg-0.4.9_p20050226-r3.ebuild:145: preplib /usr sys-libs/lib-compat/lib-compat-1.4.1.ebuild:41: preplib /usr sys-libs/lib-compat/lib-compat-1.4.ebuild:41: preplib /usr
(In reply to comment #15) > Remaining packages: > media-video/ffmpeg/ffmpeg-0.4.9_p20050226-r3.ebuild:145: preplib /usr > sys-libs/lib-compat/lib-compat-1.4.1.ebuild:41: preplib /usr > sys-libs/lib-compat/lib-compat-1.4.ebuild:41: preplib /usr > Remaining packages: > sys-libs/lib-compat/lib-compat-1.4.1.ebuild:41: preplib /usr > sys-libs/lib-compat/lib-compat-1.4.ebuild:41: preplib /usr Should be sufficient to just remove preplib by now, right? Time to close this ancient bug! (removing media-video because ffmpeg doesn't use preplib)
sys-libs/lib-compat is the only one left now: sys-libs/lib-compat/lib-compat-1.4.1.ebuild:41: preplib /usr sys-libs/lib-compat/lib-compat-1.4.ebuild:41: preplib /usr
ive added lib-compat-1.4.2 with files renamed/dropped
that means we're done here, then?
i dont think things are "done" until preplib is dropped from portage/PMS
It looks to me like: PMS doesn't mention preplib. paludis doesn't have it. pkgcore has preplib and preplib.so. portage has only preplib (with a deprecation warning since almost 5 years) Any objections against removing it?
It's removed in git: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=811689f349a91b44448bc8e294903abf990eac45
preplib is still used in the tree, namely by stable sys-libs/lib-compat. Readding base-system to CC.
We shouldn't remove it as long as the stable libcompat ebuilds still use it. It's back in now: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=163a42fb35ad95b7d44136a1fc749e0bf6d47267
(In reply to comment #23) > preplib is still used in the tree, namely by stable sys-libs/lib-compat. > Readding base-system to CC. There are no references left in the tree now, so I've removed it for the next release: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=d0d62ba0ea6375d53db8843eb938f74613583455
This is fixed in 2.1.11.53 and 2.2.0_alpha164.