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
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
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