1 |
On Mon, 18 May 2009 22:47:30 +0200 |
2 |
Patrick Lauer <patrick@g.o> wrote: |
3 |
> > No, they're temporary except when things go wrong, at which point |
4 |
> > there's no indication that they'll be fixed. |
5 |
> > |
6 |
> When things go wrong they go wrong. Indeed. |
7 |
|
8 |
When things go wrong, they go wrong beyond the scope of the failure in |
9 |
question. |
10 |
|
11 |
> > > Which either means that the deps are wrong/incomplete or that |
12 |
> > > portage has algorithmic flaws which should be corrected. |
13 |
> > > I'd expect you to at least point to the relevant bugs and not just |
14 |
> > > state some emotional mumbo-jumbo. |
15 |
> > Look at the new slot deps in EAPI 3. |
16 |
> So the deps were not precise enough, and now we improve that. Which |
17 |
> means that portage will only get more precise in the future. Awesome! |
18 |
|
19 |
...and until they're in wide use, Portage's assumptions are dangerous. |
20 |
|
21 |
> > No, broke. What he did was in direct violation of PMS and in direct |
22 |
> > violation of assumptions made by many packages. |
23 |
> So PMS did once again not reflect reality, and there were some buggy |
24 |
> packages. |
25 |
|
26 |
Uhm. No. PMS reflected how Portage used to work, and packages relied |
27 |
upon how Portage used to work. |
28 |
|
29 |
> Maybe we should spend more time on making PMS a standard |
30 |
> that documents current and past behavior instead of omitting things |
31 |
> (mtime, bash 3.1) or keeping it ambiguous so that two implementations |
32 |
> can be compliant while delivering incompatible results? |
33 |
|
34 |
Uhm. PMS correctly reflects current and past behaviour on those issues. |
35 |
|
36 |
> > > > * work by explaining the reason for the blocker, rather than |
37 |
> > > > sort-of stating the expected resolution. |
38 |
> > > |
39 |
> > > That's dumb ;) (Sorry, emotional statement) |
40 |
> > > I mean, it does not help to solve the issue and requires user |
41 |
> > > interaction where an automated solution has been working reliably |
42 |
> > > for quite some time. |
43 |
> > |
44 |
> > Uhm. Knowing the reason for the block lets the package manager solve |
45 |
> > the problem in the most intelligent available way. Merely being |
46 |
> > sort-of told the expected resolution does not. |
47 |
> You're contradicting yourself there - until now you only mentioned |
48 |
> user- visible messages, which now suddenly become hints for the |
49 |
> package manager. |
50 |
|
51 |
Re-read what I said, alongside the original discussion on replacing |
52 |
blockers. "Explaining" is not exclusively limited to the user. |
53 |
|
54 |
> Now I do wonder what you can "explain" about a block - "some files |
55 |
> collide" ? How does that help the package manager decide what to do? |
56 |
> What can it do, except unmerging one package or refusing to merge |
57 |
> another one? How does that differ from the portage solution to the |
58 |
> blocker situation? |
59 |
|
60 |
Yes, that's one explanation you'd give to the package manager. As |
61 |
you'll recall from your reading of the previous discussion, there are |
62 |
four different ways in which blockers are commonly used, and the |
63 |
best response from the package manager to each situation is different. |
64 |
|
65 |
> > A tree requirement is one that comes about as a result of studying |
66 |
> > what ebuilds do now and what they'd like to do in the future, |
67 |
> > rather than one that comes around based upon what someone happens |
68 |
> > to code. |
69 |
> I am confused. I did not think that ebuilds have desires, so I have |
70 |
> no idea what they'd like to do in the future. And it does in no way |
71 |
> tell me what a tree requirement is (unless you mean happy photons, |
72 |
> which are emitted by free- range ebuilds when you try to source them |
73 |
> in the kitchen) |
74 |
|
75 |
Then I suggest you take some basic English classes. |
76 |
|
77 |
> Incidentally most of our ebuilds are based upon what someone happened |
78 |
> to code. |
79 |
|
80 |
But the ebuild design (or at least the clean parts of it...) is not. |
81 |
|
82 |
> > ...except for the things that it broke, which necessitated |
83 |
> > shoving !! blocks in at the last minute. And I'll remind you that |
84 |
> > there were discussions about a proper blocker solution before Zac |
85 |
> > went and did his thing, |
86 |
> bikeshedding and circular reasoning in large amounts, stalling any |
87 |
> progress for a long time ... until someone provided a working |
88 |
> implementation that solved a large enough amount of issues to gain |
89 |
> the support of the majority of devs (and big cheers from so many |
90 |
> users!). |
91 |
|
92 |
Funnily enough, the original discussion was extremely productive and |
93 |
didn't involve any of the nonsense you're coming up with now. |
94 |
|
95 |
> (If it had been as bad as you suggest council would have |
96 |
> banninated it within the shortest amount of time...) |
97 |
|
98 |
That was back in the bad old days before the Council agreed to step in |
99 |
when Portage did that kind of thing. In fact, the blocker changes were |
100 |
one of the things that lead to the Council saying "in future, we'll |
101 |
package.mask Portage if it does that kind of behaviour change again". |
102 |
|
103 |
> > and the overwhelming view |
104 |
> |
105 |
> a minority view, but let's not get distracted by such subjective |
106 |
> matters. |
107 |
|
108 |
Please point me to people involved in the discussion who did not agree |
109 |
with the views presented. Provide a list of message IDs to support your |
110 |
claim. |
111 |
|
112 |
-- |
113 |
Ciaran McCreesh |