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