On Sat, Sep 23, 2006 at 06:20:44AM -0400, Mike Frysinger wrote: > On Thursday 21 September 2006 11:08, Brian Harring wrote: > > On Thu, Sep 21, 2006 at 10:43:11AM -0400, Mike Frysinger wrote: > > > i'm referring to the specific file of course, not anything else in the > > > package ... so integrating the hack eutils.eclass:preserve_old_lib() into > > > portage so it isnt a hack (not a knock against the current implementation > > > here; it's always going to be a hack until portage manages proper > > > unmerging of the ABI library) > > > > The reason folks aren't talking about using NEEDED is that NEEDED data > > is generated _after_ building; > > as well it should be ... trying to enumerate the linking ABI possibilities > before hand is not doable and not worth wasting the time of maintainers when > it can be automated > > > getting the info into the resolver > > up front allows for a helluva lot more options, and makes stuff like > > ensuring you have all sources required downloaded *prior* actually > > simple to do, rather then inserting recalculating hacks into the > > resolver. > > rather than integrating it all into the resolver in a one-pass system, a two > pass system would work: > - build all the packages requested > - after each package, if an ABI library is being removed, check to see if it > is needed by any other package. if it is needed, record it and preserve it > and move on
You're assuming that after the merge of the pkg that breaks compatibility, building is actually _still_ possible for the depends. 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. Because we don't classify the type of build time dep, that means each DEPEND match must have it's run time depends (RDEPEND) satisfied prior to being usable as a DEPEND; that right there punches a whole in the "delay till the end" approach, and is a good example of what I mean when I say "this is unbounded resolution"; the only way to solve it is to redo the resolution between finished building and merging the pkg to determine if it will break any required DEPENDS for later steps. > - 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. Which is fairly nasty, especially if you factor in the user potential of ctrl+c'ing it. Finally, if I'm interpretting your statement there correctly, still isn't guranteed to work- just having the lib around doesn't mean that the older package is left in a working state with the new partially merged over it, only way that would work is if the two were slotted (indicating they could coexist on disk). ~harring
pgpW99BPE62sk.pgp
Description: PGP signature
