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
pgpmiqh87n1FA.pgp
Description: PGP signature
