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