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

[Brian Harring <ferringb@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3152 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]