1 |
On Monday 18 May 2009 21:20:10 Ciaran McCreesh wrote: |
2 |
> On Mon, 18 May 2009 21:08:25 +0200 |
3 |
> |
4 |
> Patrick Lauer <patrick@g.o> wrote: |
5 |
> > In terms of the on-disk result it's invariant, the result is what |
6 |
> > you'd expect. There are intermediate stages that are "inconsistent" / |
7 |
> > "unclean", but as these are known and temporary they are an |
8 |
> > acceptable solution. |
9 |
> |
10 |
> No, they're temporary except when things go wrong, at which point |
11 |
> there's no indication that they'll be fixed. |
12 |
> |
13 |
When things go wrong they go wrong. Indeed. |
14 |
At the moment I can't think of an obvious failure mode, so I guess I'll have |
15 |
to wait for you to refresh my memory. Until then I'll just be happy that KDE, |
16 |
poppler, e2fsprogs and a few other apps refused to fail and saved me lots of |
17 |
time and trouble (and some failure modes that are really frustrating) by just |
18 |
magically upgrading in the right sequence, avoiding error-prone user |
19 |
interaction (e2fsprogs had one funny bug that a few hundred users found) and |
20 |
allowing me to be a lazy cat. |
21 |
|
22 |
> > > It's unrealistic to assume that depclean's going to be accurate at |
23 |
> > > every given moment, especially given Portage's massively |
24 |
> > > overoptimistic treatment of slots. It's also a very bad idea to |
25 |
> > > remove packages without the user explicitly giving permission to do |
26 |
> > > so. |
27 |
> > |
28 |
> > Which either means that the deps are wrong/incomplete or that portage |
29 |
> > has algorithmic flaws which should be corrected. |
30 |
> > I'd expect you to at least point to the relevant bugs and not just |
31 |
> > state some emotional mumbo-jumbo. |
32 |
> Look at the new slot deps in EAPI 3. |
33 |
So the deps were not precise enough, and now we improve that. Which means that |
34 |
portage will only get more precise in the future. Awesome! |
35 |
|
36 |
> No, broke. What he did was in direct violation of PMS and in direct |
37 |
> violation of assumptions made by many packages. |
38 |
So PMS did once again not reflect reality, and there were some buggy packages. |
39 |
Maybe we should spend more time on making PMS a standard that documents |
40 |
current and past behavior instead of omitting things (mtime, bash 3.1) or |
41 |
keeping it ambiguous so that two implementations can be compliant while |
42 |
delivering incompatible results? |
43 |
And then ... well ... bugs are there to be fixed. |
44 |
|
45 |
> > > * work by explaining the reason for the blocker, rather than sort-of |
46 |
> > > stating the expected resolution. |
47 |
> > |
48 |
> > That's dumb ;) (Sorry, emotional statement) |
49 |
> > I mean, it does not help to solve the issue and requires user |
50 |
> > interaction where an automated solution has been working reliably for |
51 |
> > quite some time. |
52 |
> |
53 |
> Uhm. Knowing the reason for the block lets the package manager solve |
54 |
> the problem in the most intelligent available way. Merely being sort-of |
55 |
> told the expected resolution does not. |
56 |
You're contradicting yourself there - until now you only mentioned user- |
57 |
visible messages, which now suddenly become hints for the package manager. |
58 |
|
59 |
Don't try to confuse issues like that. |
60 |
|
61 |
Now I do wonder what you can "explain" about a block - "some files collide" ? |
62 |
How does that help the package manager decide what to do? What can it do, |
63 |
except unmerging one package or refusing to merge another one? How does that |
64 |
differ from the portage solution to the blocker situation? |
65 |
|
66 |
> Automated resolution is not always possible |
67 |
Indeed, in such cases you can let the package manager abort |
68 |
|
69 |
> or a good idea. |
70 |
Again a subjective thing. This bacon here, buying that was a good idea. I |
71 |
should give you some, it's totally awesome! |
72 |
|
73 |
|
74 |
> Also, |
75 |
> having more information available for the user and being able to |
76 |
> suggest an automated resolution are not in the least bit contradictory. |
77 |
... which means that we can let the package manager handle all the "obvious" |
78 |
cases and try to give the user more information in the rare cases where it |
79 |
cannot find a valid solution on its own. Cool. |
80 |
|
81 |
> > > * be based around tree requirements, not some side effects of some |
82 |
> > > code someone happened to write without considering the implications. |
83 |
> > |
84 |
> > What is a tree requirement? (Nice buzzword btw) |
85 |
> |
86 |
> A tree requirement is one that comes about as a result of studying what |
87 |
> ebuilds do now and what they'd like to do in the future, rather than |
88 |
> one that comes around based upon what someone happens to code. |
89 |
I am confused. I did not think that ebuilds have desires, so I have no idea |
90 |
what they'd like to do in the future. And it does in no way tell me what a |
91 |
tree requirement is (unless you mean happy photons, which are emitted by free- |
92 |
range ebuilds when you try to source them in the kitchen) |
93 |
|
94 |
Incidentally most of our ebuilds are based upon what someone happened to code. |
95 |
Personally I think that many upstream devs didn't have a great plan (or at |
96 |
least they didn't like to express it in the code ;) ) and still we have an |
97 |
ebuild based upon their coding, uhm, accidents. But we adapt to it, and the |
98 |
result is quite impressive. |
99 |
|
100 |
Somewhere a while ago I read a funny idea - the more rules a contract needs |
101 |
the less trust there is. If you trust someone you agree, shake hands, deal |
102 |
complete. Only if there is not enough trust do you need lawyers, notaries and |
103 |
politicians. A long time ago we used to be able to just agree how things work |
104 |
... now we have a ton of legalese (PMS) and things get more confusing every |
105 |
day. I don't think this evolution towards self-sustaining bureaucracy and |
106 |
incessant lawyering is useful for the end users. |
107 |
|
108 |
> > And as many devs and users benefit quite a lot from the portage |
109 |
> > solution, which zmedico did not dream up without thinking about the |
110 |
> > impact on users, I find it very rude and condescending of you to |
111 |
> > disrespect the solution without offering an alternative. |
112 |
> |
113 |
> ...except for the things that it broke, which necessitated shoving !! |
114 |
> blocks in at the last minute. And I'll remind you that there were |
115 |
> discussions about a proper blocker solution before Zac went and did his |
116 |
> thing, |
117 |
bikeshedding and circular reasoning in large amounts, stalling any progress |
118 |
for a long time ... until someone provided a working implementation that |
119 |
solved a large enough amount of issues to gain the support of the majority of |
120 |
devs (and big cheers from so many users!). |
121 |
(If it had been as bad as you suggest council would have banninated it within |
122 |
the shortest amount of time...) |
123 |
|
124 |
> and the overwhelming view |
125 |
a minority view, but let's not get distracted by such subjective matters. |
126 |
|
127 |
> was that a solution based around the |
128 |
> things I've been discussing was what was wanted. |
129 |
So your point of view is that the solution proposed by you is the best. |
130 |
Intriguing. Circular, subjective, but not really convincing. |
131 |
|
132 |
> > As you seem to understand the problem domain I'd expect a coherent |
133 |
> > unambiguous proposal instead of vague accusations and emotional terms |
134 |
> > that do not help in any way to improve the situation. |
135 |
> |
136 |
> See the discussions we had back when the only kind of blocker was a |
137 |
> hard, single ! block. |
138 |
I'm not aware of a complete proposal in those discussions. Mind giving me a |
139 |
link to that one so I don't have to spend lots of time trying to track it down |
140 |
in the almost 70000 mails archived by gmane? |