1 |
On Sat, Sep 29, 2012 at 11:55:22AM +0200, Micha?? G??rny wrote: |
2 |
> On Wed, 26 Sep 2012 03:29:17 -0700 |
3 |
> Brian Harring <ferringb@×××××.com> wrote: |
4 |
> |
5 |
> > On Wed, Sep 26, 2012 at 08:02:44AM +0200, Micha?? G??rny wrote: |
6 |
> > > On Tue, 25 Sep 2012 12:54:39 -0700 |
7 |
> > > Brian Harring <ferringb@×××××.com> wrote: |
8 |
> > > |
9 |
> > > > On Tue, Sep 25, 2012 at 08:58:07PM +0200, Micha?? G??rny wrote: |
10 |
> > > > > On Tue, 25 Sep 2012 14:47:33 -0400 |
11 |
> > > > > Ian Stakenvicius <axs@g.o> wrote: |
12 |
> > > > > |
13 |
> > > > > > Based on the above I do expect the reference implementation would also |
14 |
> > > > > > need to change. I expect, for instance, that the PM's |
15 |
> > > > > > metadata-handling would need to occur as normal even though none of |
16 |
> > > > > > the package's phase functions would run, that is, *DEPEND |
17 |
> > > > > > (realistically RDEPEND as that should be the only one affected here, |
18 |
> > > > > > maybe PDEPEND too) and USE/PKGUSE would get updated. Since portage |
19 |
> > > > > > would not be re-emerging the package from the tree the original ebuild |
20 |
> > > > > > would remain. |
21 |
> > > > > |
22 |
> > > > > Yes, unless I'm missing something that's the intent. I will re-read |
23 |
> > > > > and update the GLEP a bit sometime this week. |
24 |
> > > > |
25 |
> > > > There's a fairly strong user interaction component here, along w/ |
26 |
> > > > potential nastyness for ebuilds (the proposal assume that a flag will |
27 |
> > > > be toggable in all cases within an ebuild if IUSE_RUNTIME specified; I |
28 |
> > > > guarantee instances where that fails can be found in the tree if a |
29 |
> > > > basic audit was done). Additionally, this *is* useless if it's done |
30 |
> > > > in a form the UI an't display/handle; Ciaran may bitch about |
31 |
> > > > REQUIRED_USE's UI (which I knew going in was going to be |
32 |
> > > > problematic, just to be clear), but he's right on that front. |
33 |
> > |
34 |
> > ^^^ This point still needs addressing. |
35 |
> |
36 |
> What kind of addressing? The user interaction works like usual -- |
37 |
> portage lists a bunch of flags, some of them may have additional |
38 |
> hammers or sickles to mean that they will not trigger the rebuild. |
39 |
> Nothing more is required. |
40 |
> |
41 |
> What is even more important, there is nothing new to learn |
42 |
> for the user. In fact, he doesn't need anything new from UI. He will |
43 |
> just set the flag like he did 10 years ago. |
44 |
|
45 |
1) REQUIRED_USE interaction. That's a rats nest, trust me on that |
46 |
one. If your proposal is to just to have people tweak, get yelled at |
47 |
by the pm, tweak, etc, well, on behalf of users, thanks a lot. |
48 |
|
49 |
2) While hard to comment since your 'updated' glep wasn't fully |
50 |
updated- now is self inconsistent (minimally, trace backwards |
51 |
compatibility; fix it in full next time)... you're not exactly |
52 |
covering how this will go; best I can figure, you just want to shove |
53 |
yet another coloring (great for color blind people) or syntax markup |
54 |
on emerge -pv style output, somehow indicating runtime toggable or |
55 |
not; this is getting picked at because that display already is a |
56 |
crapfest and overloaded. |
57 |
|
58 |
3) You're ignoring cycles here; specifically suggested dep based |
59 |
cycles that influence the originating node, and how that is |
60 |
represented- this isn't counting representing during --tree mode what |
61 |
is brought in where/when because of it. |
62 |
|
63 |
4) Finally, and more damningly, you're ignoring apps like porthole. |
64 |
You need to think long/hard about how *exactly* porthole is going to |
65 |
indicate to users what optionals are there- more importantly, what |
66 |
those optionals induce/require (that's where it truly gets ugly and |
67 |
your lack of dep resolver knowledge, and unwillingness to do a patch |
68 |
and learn the basics there become infuriating); || () or blockers w/in |
69 |
suggested alone are going to make things painful. |
70 |
|
71 |
|
72 |
> > > > Additionally, this needs to be thought out how it'll interact with |
73 |
> > > > eclasses; what stacking, etc. It doesn't cover the basics there to |
74 |
> > > > say the least. |
75 |
> > > |
76 |
> > > The proposal didn't cover eclasses at all. Is there a need to do so or |
77 |
> > > are we chasing some kind of perfection based on filling all unused |
78 |
> > > slots? |
79 |
> > |
80 |
> > Eclass stacking here matters; if it's stacked, it means ebuilds have |
81 |
> > to use out of bound (ie, other vars) to tell the eclass when it |
82 |
> > shouldn't mark a flag as runtime toggable. If it's not stacked by |
83 |
> > the pm, then they have to manually stack; that differs from the norm |
84 |
> > and makes it easier to screwup; however; does allow for them to |
85 |
> > filter, albeit a slight pain in the ass doing so. |
86 |
> > |
87 |
> > There's a choice there, and the answer matters, so yes, you should |
88 |
> > actually have a complete glep before trying to shove it up to the |
89 |
> > council and extract a vote out of them. Lest the intention is to just |
90 |
> > have them kick it back to the curb... |
91 |
> |
92 |
> As others have said, we're not stacking it. Using it in eclasses |
93 |
> is whacky and should be avoided. End of the story. |
94 |
|
95 |
It's your proposal there boss. That's a stupid decision, but as said, |
96 |
your proposal to run into the ground if you'd like. |
97 |
|
98 |
However. I suggest you actually document that in your proposal that |
99 |
it breaks from the stacking norm. Also, drop the backwards |
100 |
compatibility claim at the bottom. |
101 |
|
102 |
It was bullshit before, the fact I keep having to picking at this |
103 |
means I'm going to start doing so in creative ways; thus I'll just |
104 |
quote an exchange from 'the carnival'- it's "pure beeship, beeship, |
105 |
not true, false, Beeship!" "oh... bullshit" "Oui!". Quote wasn't a |
106 |
perfect fit, but I'm getting tired of having to use the plain |
107 |
'bullshit' response for your emails. |
108 |
|
109 |
|
110 |
> > > > Pretty much, this needs an implementation, partial conversion of the |
111 |
> > > > tree to demonstrate it. |
112 |
> > > > |
113 |
> > > > Just to prove that fricking point; if you had tried implementing this, |
114 |
> > > > a full investigation of what's involved alone, you'd have spotted that |
115 |
> > > > the core of the proposal is based on a wrong assumption. |
116 |
> > > > |
117 |
> > > > Portage doesn't write unfinalized DEPEND/RDEPEND/PDEPEND to the VDB. |
118 |
> > > |
119 |
> > > There's a footnote there, saying: |
120 |
> > > |
121 |
> > > The package manager has to ensure that all relevant information is |
122 |
> > > stored in the installed package metadata. |
123 |
> > |
124 |
> > Frankly I don't fully buy that you were aware of this issue from the |
125 |
> > start of the proposal; the wording partially covers it however. |
126 |
> > Ddoesn't call it out, but via tha req it dumps it on the package |
127 |
> > manager developers heads to sort it- which already is the case. |
128 |
> > Binpkgs minimally weren't addressed which is why I still don't think |
129 |
> > this was actually spotted up front. |
130 |
> |
131 |
> We talked about it, don't you remember? |
132 |
|
133 |
Think you're being cracky there; the point I made there was that your |
134 |
proposal didn't address the need for unfinalized across all bulit |
135 |
deps- there was no discussion about that. |
136 |
|
137 |
|
138 |
> That's why I have updated |
139 |
> the spec and put the whole implementation details thing with special |
140 |
> note what needs to be stored in metadata. |
141 |
|
142 |
Not going to give you an inch on this shit anymore; Gleps are derived |
143 |
from PEPs; standard to include the cons of a proposal, in this case |
144 |
you actually need to quantify/document the perf hit (portage in |
145 |
particular) in there. |
146 |
|
147 |
As for "updated to cover it"... meh. I read that section; you're |
148 |
requirements of the PM imply we can always extract out the relevant |
149 |
bits from the original source trees. |
150 |
|
151 |
Simple example, |
152 |
encode? ( || ( x? ( blah ) y:=* ) ) |
153 |
|
154 |
with x being an IUSE_RUNTIME toggle. Try extracting that. It's a |
155 |
PITFA; partial rendering of all non IUSE_RUNTIME for the full tree, |
156 |
storing that tree in full, is what's required- that example |
157 |
demonstrates why thinking "just extract the parts" is cracked out |
158 |
(bluntly: moreso naive, as ciaran said, if you dick around w/ this |
159 |
level of the managers code, you're going to find that sort of thing |
160 |
intractable because of the rules of the syntax). |
161 |
|
162 |
|
163 |
Finally, going to fold in a snippet from ciaran/you in a separate |
164 |
branch of this thread: |
165 |
|
166 |
On Sat, Sep 29, 2012 at 08:43:14PM +0200, Micha?? G??rny wrote: |
167 |
> On Sat, 29 Sep 2012 17:13:14 +0100 |
168 |
> Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> wrote: |
169 |
> > You've also still not provided any kind of reference implementation, |
170 |
> > and your "reference implementation" section is still written with a |
171 |
> > complete lack of awareness of how dependency resolution is actually |
172 |
> > done. |
173 |
> |
174 |
> I'm sorry I haven't got time yet to write a package manager. I promise |
175 |
> I will do it as soon as I have time to do so. Thank you for your |
176 |
> patience. |
177 |
|
178 |
Good news! |
179 |
|
180 |
You don't have to write a PM from scratch- just modify portage to |
181 |
prototype it. We realize how annoying it is to have your time wasted, |
182 |
thus a patch is enough. Enjoy! |
183 |
|
184 |
|
185 |
1) Don't be a tool. Also, if you want to write a PM, I suggest you do |
186 |
so- the timbre of your proposals would likely shift towards sanity (or |
187 |
at least things would be quieter while you're off having at it with a |
188 |
windmill). |
189 |
2) PMS requires portage support exist before a patch goes in; you've |
190 |
got to do that anyways if you actually think this is going anywhere. |
191 |
3) The things the PM authors are beating you over the head with all |
192 |
map back to realities at the implementation level; if you'd get off |
193 |
your ass and do it rather than arguing, you'd be getting further with |
194 |
your proposal (or find it nonviable, and do a different proposal). |
195 |
|
196 |
|
197 |
Honestly, your proposal doesn't feel like "optional deps"; it feels |
198 |
like you're just trying to shove in an efficiency hack to avoid |
199 |
rebuilds in certain cases, rather than designing a system for exposing |
200 |
suggested deps to people. Efficiency hack doesn't involve a heavy |
201 |
UI angle, optiional/suggested deps do. |
202 |
|
203 |
Either way, I'm done w/ this proposal; you come up w/ a prototype, |
204 |
I'll look, till then this is a waste of time. |
205 |
|
206 |
Should the council/folk care, consider that a strong -1 on my part. |
207 |
~harring |