Re: [gentoo-dev] RFC about another *DEPEND variable

[Mike Frysinger]

On Saturday 23 September 2006 10:30, Brian Harring wrote:
> dlopen?

we already said that this will need a new depend variable

> How does this fix openssl horkage? (bad soname handling)

it wont, but such things are broken regardless outside of Gentoo ... and 
trying to accommodate something that happens every three blue moons at the 
cost of developer time is not worth it

> Also... what do we do for python/perl (*-updater scripts in general)
> where a change in a pkg state means we have to rebuild the revdeps?

my solution does not address this, but what you're proposing would over 
address this ... how do you know when a package needs to be rebuilt (a perl 
module) or rebuilding is a waste of time (a package installs perl scripts 
that execute `perl` and nothing else)

> What you're suggesting works for strictly linkage; still think this
> shouuld work for the general problem rather then just one subset.

yes, i am addressing what i see to be the most critical issue and the easiest 
to break a user's system

> Clarifying my statement; we don't break our DEPEND down into "this is
> what is executed in building the package" (toolchain),

DEPEND

> vs "this is the
> crap the binaries we build against need avail to be linked against",
> literally what winds up as -l args.

RDEPEND

> If punting the old lib (as I assumed), means we would potentially be
> making certain DEPEND atoms unusable if they're required in an
> execution context (rather then just winding up as a -l arg).

no ... lemme give a perfect example.

user has openssl-0.9.7j installed and they upgrade to openssl-0.9.8c ... the 
old version provided SONAME files libcrypto.so.0.9.7 and libssl.so.0.9.7 
while the new one provides SONAME files libcrypto.so.0.9.8 and 
libssl.so.0.9.8

everything from openssl-0.9.7j is unmerged except for the two files 
libcrypto.so.0.9.7 and libssl.so.0.9.7.  openssl-0.9.8c, being a different 
ABI, does not provide these files thus there is no clash.

portage keeps track of libcrypto.so.0.9.7 and libssl.so.0.9.7 and once no more 
packages have NEEDED entries for these, will silently clean them out

openssl is odd in that it encodes .x.y.z version into the ABI ... if we use 
the more common example with say expat, older versions install 
libexpat.so.0.1, libexpat.so.0.2, libexpat.so.0.3, etc... but the ABI SONAME 
is still just libexpat.so.0.  when the next major version of expat comes out, 
the SONAME is bumped to libexpat.so.1 and portage needs to keep around the 
last libexpat.so.0

> In that case, wouldn't mind a response to the "what about ctrl+c
> during the run?"  The potential for orphaning there sucks; recording
> the old library in the new version sucks also since it complicates the
> merge process, that lib *must* be removed else it's a potential
> collision-protect minefield.

- portage merges new version 2 to $ROOT
- system now has version 1 and version 2 in $ROOT
- portage starts to clean out version 1 from $ROOT
- do not fully trim version 1's vdb until version 2 has been updated with the 
new information

so ctrl+c at any point and so what ?  you dont remove old files until new 
files are fully placed and you can resume at any point

> Finally, even if the lib is temporarily left behind, this solution
> doesn't gurantee the library actually would *work* still- it only can
> work if the lib is standalone from the rest of the pkg and doesn't
> rely on any external data from the pkg.

we're talking about preserving the system long enough to rebuild things; we're 
not talking about keeping the system forever in a sane state.

i would guess that this corner case is not the norm and thus we can ignore it 
as the situation is still a lot better than what we have now:
 $ foo
 foo: error while loading shared libraries: libbar.so.1: cannot open shared 
object file: No such file or directory

awesome

> Basically trying to point out that what you're proposing only works in
> a subset of the cases revdep must deal with, and that revdep itself
> doesn't deal with *all* situations as is; hence BINCOMPAT as a way to
> try and shift it under maintainers control.

revdep-rebuild doesnt take into consideration any of the issues you raised

and forcing maintainers to always track BINCOMPAT is unwieldy ... a single 
package provides multiple SONAMEs ?  bitrot ?  SONAME is dynamic based upon 
architecture or USE flags ?
-mike