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 |