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
pgpq4H5zbMG0Q.pgp
Description: PGP signature
