Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Mike Frysinger <vapier@g.o>
Subject: Re: RFC about another *DEPEND variable
Date: Sat, 23 Sep 2006 23:31:12 -0400
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
Attachment:
pgpY67wgAKTj8.pgp (PGP signature)
Replies:
Re: RFC about another *DEPEND variable
-- Brian Harring
References:
RFC about another *DEPEND variable
-- Alin Nastac
Re: RFC about another *DEPEND variable
-- Mike Frysinger
Re: RFC about another *DEPEND variable
-- Brian Harring
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: RFC about another *DEPEND variable
Next by thread:
Re: RFC about another *DEPEND variable
Previous by date:
Re: baselayout-1.12.5 sucks
Next by date:
Re: RFC about another *DEPEND variable


Updated Jun 17, 2009

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.