1 |
On Wed, Sep 26, 2012 at 08:02:44AM +0200, Micha?? G??rny wrote: |
2 |
> On Tue, 25 Sep 2012 12:54:39 -0700 |
3 |
> Brian Harring <ferringb@×××××.com> wrote: |
4 |
> |
5 |
> > On Tue, Sep 25, 2012 at 08:58:07PM +0200, Micha?? G??rny wrote: |
6 |
> > > On Tue, 25 Sep 2012 14:47:33 -0400 |
7 |
> > > Ian Stakenvicius <axs@g.o> wrote: |
8 |
> > > |
9 |
> > > > Based on the above I do expect the reference implementation would also |
10 |
> > > > need to change. I expect, for instance, that the PM's |
11 |
> > > > metadata-handling would need to occur as normal even though none of |
12 |
> > > > the package's phase functions would run, that is, *DEPEND |
13 |
> > > > (realistically RDEPEND as that should be the only one affected here, |
14 |
> > > > maybe PDEPEND too) and USE/PKGUSE would get updated. Since portage |
15 |
> > > > would not be re-emerging the package from the tree the original ebuild |
16 |
> > > > would remain. |
17 |
> > > |
18 |
> > > Yes, unless I'm missing something that's the intent. I will re-read |
19 |
> > > and update the GLEP a bit sometime this week. |
20 |
> > |
21 |
> > There's a fairly strong user interaction component here, along w/ |
22 |
> > potential nastyness for ebuilds (the proposal assume that a flag will |
23 |
> > be toggable in all cases within an ebuild if IUSE_RUNTIME specified; I |
24 |
> > guarantee instances where that fails can be found in the tree if a |
25 |
> > basic audit was done). Additionally, this *is* useless if it's done |
26 |
> > in a form the UI an't display/handle; Ciaran may bitch about |
27 |
> > REQUIRED_USE's UI (which I knew going in was going to be |
28 |
> > problematic, just to be clear), but he's right on that front. |
29 |
|
30 |
^^^ This point still needs addressing. |
31 |
|
32 |
|
33 |
> > Additionally, this needs to be thought out how it'll interact with |
34 |
> > eclasses; what stacking, etc. It doesn't cover the basics there to |
35 |
> > say the least. |
36 |
> |
37 |
> The proposal didn't cover eclasses at all. Is there a need to do so or |
38 |
> are we chasing some kind of perfection based on filling all unused |
39 |
> slots? |
40 |
|
41 |
Eclass stacking here matters; if it's stacked, it means ebuilds have |
42 |
to use out of bound (ie, other vars) to tell the eclass when it |
43 |
shouldn't mark a flag as runtime toggable. If it's not stacked by |
44 |
the pm, then they have to manually stack; that differs from the norm |
45 |
and makes it easier to screwup; however; does allow for them to |
46 |
filter, albeit a slight pain in the ass doing so. |
47 |
|
48 |
There's a choice there, and the answer matters, so yes, you should |
49 |
actually have a complete glep before trying to shove it up to the |
50 |
council and extract a vote out of them. Lest the intention is to just |
51 |
have them kick it back to the curb... |
52 |
|
53 |
|
54 |
> > Pretty much, this needs an implementation, partial conversion of the |
55 |
> > tree to demonstrate it. |
56 |
> > |
57 |
> > Just to prove that fricking point; if you had tried implementing this, |
58 |
> > a full investigation of what's involved alone, you'd have spotted that |
59 |
> > the core of the proposal is based on a wrong assumption. |
60 |
> > |
61 |
> > Portage doesn't write unfinalized DEPEND/RDEPEND/PDEPEND to the VDB. |
62 |
> |
63 |
> There's a footnote there, saying: |
64 |
> |
65 |
> The package manager has to ensure that all relevant information is |
66 |
> stored in the installed package metadata. |
67 |
|
68 |
Frankly I don't fully buy that you were aware of this issue from the |
69 |
start of the proposal; the wording partially covers it however. |
70 |
Ddoesn't call it out, but via tha req it dumps it on the package |
71 |
manager developers heads to sort it- which already is the case. |
72 |
Binpkgs minimally weren't addressed which is why I still don't think |
73 |
this was actually spotted up front. |
74 |
|
75 |
Were it, the performance impact should've been mentioned, and |
76 |
quantified; con's are part of a normal glep. |
77 |
|
78 |
Meaning.. wait for it... writing a prototype is required to get those |
79 |
stats. ;) |
80 |
|
81 |
|
82 |
> > > > Based on the above I do expect the reference implementation |
83 |
> > > > would alsoneed to change. I expect, for instance, that the |
84 |
> > > > PM's metadata-handling would need to occur as normal even |
85 |
> > > > though none of the package's phase functions would run, that |
86 |
> > > > is, *DEPEND (realistically RDEPEND as that should be the only |
87 |
> > > > one affected here, maybe PDEPEND too) and USE/PKGUSE would get |
88 |
> > > > updated. Since portage would not be re-emerging the package |
89 |
> > > > from the tree the original ebuild |
90 |
> > > > would remain. |
91 |
> > > > |
92 |
> > > > I expect, as a corollary to this, that a rebuild would be necessary if |
93 |
> > > > (on-disk-IUSE_RUNTIME xor in-ebuild-IUSE_RUNTIME) was non-empty |
94 |
> > > > (--newuse) or resulted in any flags that are in USE |
95 |
> > > > (--reinstall=changed-use). IMO this would be necessary to ensure the |
96 |
> > > > local ebuild copy and all related metadata for it gets updated in vdb. |
97 |
> > > |
98 |
> > > I think that's a common package manager logic and it's out of scope |
99 |
> > > of the GLEP. |
100 |
> > |
101 |
> > Portage doesn't do physical updates last I saw- if it did, well, |
102 |
> > that's fairly dangerous. Only thing stored in the VDB is the ebuild |
103 |
> > and the environment dump, and the environment dump is what's ran from. |
104 |
> > |
105 |
> > You cannot sanely pick part the dump and try to intermix current |
106 |
> > ebuilds; rephrasing, I'll kick in the head anyone who tries that. |
107 |
> |
108 |
> What are you talking about? As far as I can see, we are talking here |
109 |
> about *full rebuild*. |
110 |
|
111 |
Added the full quote above. Read prior to the corollary; that's |
112 |
proposing transferance of *depend from live tree to vdb; that's not |
113 |
common- portage alone does that, and it's got faults that make it |
114 |
unlikely you'll convince others to replicate that behaviour. |
115 |
|
116 |
~harring |