Gentoo Archives: gentoo-dev

From: Brian Harring <ferringb@×××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] RFC about another *DEPEND variable
Date: Sat, 23 Sep 2006 13:20:56
Message-Id: 20060923131411.GA12282@seldon
In Reply to: Re: [gentoo-dev] RFC about another *DEPEND variable by Mike Frysinger
1 On Sat, Sep 23, 2006 at 06:20:44AM -0400, Mike Frysinger wrote:
2 > On Thursday 21 September 2006 11:08, Brian Harring wrote:
3 > > On Thu, Sep 21, 2006 at 10:43:11AM -0400, Mike Frysinger wrote:
4 > > > i'm referring to the specific file of course, not anything else in the
5 > > > package ... so integrating the hack eutils.eclass:preserve_old_lib() into
6 > > > portage so it isnt a hack (not a knock against the current implementation
7 > > > here; it's always going to be a hack until portage manages proper
8 > > > unmerging of the ABI library)
9 > >
10 > > The reason folks aren't talking about using NEEDED is that NEEDED data
11 > > is generated _after_ building;
12 >
13 > as well it should be ... trying to enumerate the linking ABI possibilities
14 > before hand is not doable and not worth wasting the time of maintainers when
15 > it can be automated
16 >
17 > > getting the info into the resolver
18 > > up front allows for a helluva lot more options, and makes stuff like
19 > > ensuring you have all sources required downloaded *prior* actually
20 > > simple to do, rather then inserting recalculating hacks into the
21 > > resolver.
22 >
23 > rather than integrating it all into the resolver in a one-pass system, a two
24 > pass system would work:
25 > - build all the packages requested
26 > - after each package, if an ABI library is being removed, check to see if it
27 > is needed by any other package. if it is needed, record it and preserve it
28 > and move on
29
30 You're assuming that after the merge of the pkg that breaks
31 compatibility, building is actually _still_ possible for the depends.
32
33 We don't classify our deps as actual build depends vs link depends; as
34 such trying to (essentially) "patch things up after" allow for the
35 scenario where merging breaks the toolchain, thus building isn't
36 possible.
37
38 Because we don't classify the type of build time dep, that means each
39 DEPEND match must have it's run time depends (RDEPEND) satisfied prior
40 to being usable as a DEPEND; that right there punches a whole in the
41 "delay till the end" approach, and is a good example of what I mean
42 when I say "this is unbounded resolution"; the only way to solve it is
43 to redo the resolution between finished building and merging the pkg
44 to determine if it will break any required DEPENDS for later steps.
45
46 > - once all the packages requested have been merged, you start the second
47 > phase and calculate everything that needs to be rebuilt. as ABI libs are no
48 > longer needed on a system, portage can scrub them out
49
50 "as ABI libs are no longer needed on a system", phrasing of that
51 implies you're suggesting that portage should leave the older package
52 in place till it's updated all revdeps, then wipe it.
53
54 Which is fairly nasty, especially if you factor in the user potential
55 of ctrl+c'ing it. Finally, if I'm interpretting your statement there
56 correctly, still isn't guranteed to work- just having the lib around
57 doesn't mean that the older package is left in a working state with
58 the new partially merged over it, only way that would work is if the
59 two were slotted (indicating they could coexist on disk).
60 ~harring

Replies

Subject Author
Re: [gentoo-dev] RFC about another *DEPEND variable Mike Frysinger <vapier@g.o>