Re: [gentoo-dev] [RFC] More reliable hiding preserved libraries

["Tiziano Müller" <dev-zero@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 4019 bytes --]

Am Samstag, den 03.04.2010, 23:05 +0200 schrieb Maciej Mrozowski:
> On Saturday 03 of April 2010 14:16:14 Fabian Groffen wrote:
> > Shouldn't we fix that buildsystem then?  Do you have an example of a
> > package/buildsystem that does that?
> "We" already do, the thing is that maybe we don't have to.
> https://bugs.gentoo.org/show_bug.cgi?id=240323
> From top of my head: python having issues with sys-libs/db as well as some 
> packages with readline.
>  
> > > It would indeed. Now when I think about it, moving stuff to preserved
> > > library dir could be just done - provided it's possible - along with
> > > fixing/setting DT_RPATH's in reverse runtime dependencies. This way no
> > > system-wide LIBRARY_PATH's would be necessary.
> > > Is it possible? Mike?
> > No, unless you somehow make sure you reserve space for this, by e.g.
> > setting a bogus rpath entry at buildtime.  If you want to go that route,
> > you probably want to look at the Prefix' binutils-config wrapper that
> > already calls the linker with added rpath arguments.  Afterwards you can
> > use chrpath to set it to the correct location.  Will get messy with the
> > vdb though, but if Portage's doing it, it can probably be dealt with.
> Sounds messy indeed, what about hardened/SELinux/AppArmor/whatever - do they 
> allow such DT_RPATH operations? It should be probably also restricted for 
> binary-only packages.
> 
> On Saturday 03 of April 2010 20:51:43 Tiziano Müller wrote:
> > Don't fix the hack. Remove the preserve libs "feature", make the PMs
> > check for rdeps per default before unmerging things.
> This will only prevent creating orphans of uninstalled libraries, what about 
> upgraded ones when SOVERSION has been bumped (the most common case)?
I addressed this in the next phrase.

>  Besides I 
> can already imagine PMS-related discussion regarding "make the PMs check for 
> rdeps per default before unmerging things" - thx but no thx.
This is not related to PMS. Paludis for example does it already with the
current EAPIs.

> 
> > Slot libraries where needed, slot dep operators (EAPI 4) will help.
> Again, you suggest to SLOT every library that happened to bump SOVERSION. It's 
> unrealistic. Besides library should be slotted when it's API changes, for 
> source based distributions it's not needed for ABI changes - let's not confuse 
> those two. Also excessive slotting increases probability of breaking library 
> discovery mechanisms in various build systems (not everyone uses pkg-config).
I know that slotting can cause problems. But forcing build systems to
use specific versions of libraries is much easier than "shadowing"
libraries present in library search dirs, especially when those libs are
not even tracked by the PM.

> 
> > And if that doesn't work out we need a separate var to give the PM a hint 
> when API/ABI breakages happen (such that the PM knows when to re-install the 
> rev deps).
> It needs PMS amended and thus GLEP.
Wrong, we don't have GLEPs for >90% of the PMS changes going into EAPI-3
or 4.

>  Please submit a GLEP item for this if you 
> see it fit.
> Anyway, as explained in OT, it's not a problem of package manager dependencies 
> system but issue with broken/not smart build systems - no dependency tree 
> magic will solve this issue.
It is a problem which can _only_ be solved at the PM level. You have to
tell the PM when API breakages happen. Either by slotting the lib or by
something else. Using guesswork to determine whether or not a library
should be removed may be a temporary solution. Remember: you're
partially ignoring a users request since he wanted the package to be
removed - and we all know how things like "protect the user from
himself" end up.




-- 
Tiziano Müller
Gentoo Linux Developer
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-zero@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3551 bytes --]