On Saturday 23 September 2006 10:30, Brian Harring wrote:
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),
> vs "this is the
> crap the binaries we build against need avail to be linked against",
> literally what winds up as -l args.
> 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
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
> 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
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: error while loading shared libraries: libbar.so.1: cannot open shared
object file: No such file or directory
> 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 ?