Re: [gentoo-dev] RFC about another *DEPEND variable

[Mike Frysinger]

On Monday 25 September 2006 14:16, Brian Harring wrote:
> Bad soname handling is just *part* of what BINCOMPAT could do; it's
> not the sole reason for it's existance, as such it's not quite right
> dismissing it just because it addresses a rarity the NEEDED approach
> doesn't. :)

i dismiss it as being a real advantage and/or argument for taking BINCOMPAT 
over an automated NEEDED scan

as i said, if you have changed ABI without an ABI bump, then the upstream 
package maintainer is screwing everyone who uses the package, not just 
Gentoo ... so perhaps we should be talking to them to get the situation 
resolved for all consumers, not just Gentoo

> *IF* we actually had that in place it would enable detecting and
> rebuilding c++ code whenever gcc pulls its next c++ abi change with
> appropriate deps in place (iow, kill off the implicit system deps).

scanelf already does this ... the only time you need to rebuild is when the 
ABI breaks ... aka libstdc++.so.5 -> libstdc++.so.6

> If that were the case, why do we have libraries listed in DEPEND then?

because i have a short memory

> Bleh, this is getting back to exactly my point that it's unbounded
> resolution.  To support this, every step of execution would require
> scanning for dangling nodes to punt; aside from invalidating -p's
> output it *still* is a collision-protect hit.

when the package upgrade detects an ABI change you recalculate the packages 
that need to be rebuilt ...

dangling nodes get recorded in the new package and considering these old files 
are not detrimental to the health of the system, you can do such a cleanup 
once at the end of the emerge

> It also involves changing vdb nodes from "installed and usable" to
> "installed/usable" or "lingering"

no ... the old versions get merged into the new one as their existence is 
purely hidden

> Tracking BINCOMPAT should *not* be that hard.

it's one more thing to keep track of and considering all of the possibilities 
i outlined, a single maintainer can easily lose his sanity ... or you force 
wasted rebuilds on people when it's only needed in some circumstances

> Hell, automate a tool to determine if it's a BINCOMPAT bump via NEEDED
> data (folks should be compiling the pkg anyways), point is it's mainly
> common sense for maintainenance of it.

and when are you going to run that tool ?  when you bump the package ?  so now 
the maintainer has to test it on all the KEYWORDed arches with all the USE 
combos, or de-KEYWORD it and make the arch maintainers test it ?  or dig 
through the source code line by line and hope to catch all such cases by 
hand/eye ?

> Yes, if the solution can be automated without flinging poo into the
> code, I'm for it; that said I know what the implementation is going to
> have to look like, and it's *nasty*.

i dont think either of our solutions are satisfactory for all presented cases; 
a hybrid model would be needed
-mike