Gentoo Archives: gentoo-dev

From: Brian Harring <ferringb@×××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] RFC about another *DEPEND variable
Date: Sat, 23 Sep 2006 14:35:41
Message-Id: 20060923143020.GB12282@seldon
In Reply to: Re: [gentoo-dev] RFC about another *DEPEND variable by Mike Frysinger
On Sat, Sep 23, 2006 at 09:50:12AM -0400, Mike Frysinger wrote:
> On Saturday 23 September 2006 09:14, Brian Harring wrote: > > You're assuming that after the merge of the pkg that breaks > > compatibility, building is actually _still_ possible for the depends. > > of course i am; i just said that portage would make sure to not unmerge any > ABI lib still in use
dlopen? How does this fix openssl horkage? (bad soname handling) 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? What you're suggesting works for strictly linkage; still think this shouuld work for the general problem rather then just one subset.
> > We don't classify our deps as actual build depends vs link depends; as > > such trying to (essentially) "patch things up after" allow for the > > scenario where merging breaks the toolchain, thus building isn't > > possible. > > huh ? RDEPEND is linktime ... see my statement above
RDEPEND is execution requirements; to use the binary, this is what needs to be in the graph. 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). So... ignore that bit since you're talking about lingering files.
> > > - once all the packages requested have been merged, you start the second > > > phase and calculate everything that needs to be rebuilt. as ABI libs are > > > no longer needed on a system, portage can scrub them out > > > > "as ABI libs are no longer needed on a system", phrasing of that > > implies you're suggesting that portage should leave the older package > > in place till it's updated all revdeps, then wipe it. > > no i am not; read my previous e-mails where i said it would leave behind the 1 > ABI lib required ... aka whatever is encoded in SONAME
Yeah, missed the "presvered" (woot for 5am wakeup). 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. 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. Example would be pkg foobar that internally has libconvience, used by it's libs but not externally linked, contains (oddly enough) convience bits shared across foobars libraries. libconvience is *not* to be externally linked against, consumers must access the other libs (say libfoo); any soname bumps to libfoo, the old version gets broke in the process despite due to it linking internally against an unversioned so. Granted, semi retarded, but gnomes libegg comes to mind as a potential case of this. 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. Maintainence of it *should* be pretty simple also; for sane upstream soname handling, you just bump it with the majors; for the rest, its a knob that can be fiddled to at least give up front warning of the issue. ~harring


Subject Author
Re: [gentoo-dev] RFC about another *DEPEND variable Mike Frysinger <vapier@g.o>