1 |
On Fri, 01 Jul 2011 09:45:34 +0200 |
2 |
Sebastian Luther <SebastianLuther@×××.de> wrote: |
3 |
> >> I know. I'm not opposed to this change, but the needed work flow |
4 |
> >> change for ebuild devs has to be communicated. |
5 |
> > |
6 |
> > Shouldn't be a workflow change. It's already policy to do a revbump |
7 |
> > if dependencies change. |
8 |
> |
9 |
> It is policy, but as you're probably aware of, it's not followed in |
10 |
> may cases, which in turn raises the question if people wouldn't |
11 |
> prefer to change the policy instead of their work flow (not that I |
12 |
> would suggest that). |
13 |
|
14 |
Anyone not following the policy is already breaking things, and we |
15 |
can't switch to the "use the tree ebuild" behaviour since it doesn't |
16 |
work when ebuilds get removed. All we're doing is making an existing |
17 |
bug more visible. |
18 |
|
19 |
> I think part of the problem here is that those things aren't written |
20 |
> down as a glep (or some similar document). Imo every change that leads |
21 |
> to a non trivial amount of discussion should be written down in such a |
22 |
> way. Otherwise it's hard for people that missed the original |
23 |
> discussion to catch up and those that took part in this discussion |
24 |
> get frustrated because they have to repeat themselves again and again. |
25 |
> This should be discussed in another thread if someone is interested. |
26 |
|
27 |
It's not worth it. It's a huge amount of work to summarise every |
28 |
incorrect argument and false lead. It's not done by official standards |
29 |
bodies, who have far more resources than we do, so what you're asking |
30 |
for is just obstructionism and red tape. |
31 |
|
32 |
> > If you're just looking for a summary, not details: say a user has |
33 |
> > cat/dep:1, cat/dep:2 and cat/dep:3 installed, and wants to uninstall |
34 |
> > cat/dep:1 and cat/dep:2. Say there's cat/pkg installed which has a |
35 |
> > dep upon cat/dep. Then there's no way for the package mangler to |
36 |
> > know which cat/dep slots are still 'needed', and which can be safely |
37 |
> > removed. Thus, to be safe, it has to assume that all three slots |
38 |
> > might be needed. |
39 |
> > |
40 |
> Or you do it like portage does it and assume the package works with |
41 |
> any slot (the :* case) and if it doesn't, declare that a bug of the |
42 |
> package. Now giving ebuild devs the := operator allows them to say |
43 |
> "the package insist on the slot it was build against". |
44 |
|
45 |
Can't. Right now there's no way for packages to specify those kinds of |
46 |
dependencies correctly. Assuming :* just isn't safe, and doesn't match |
47 |
the historical meaning of lack-of-slot dependencies. |
48 |
|
49 |
> > The problem is that every way of handling the "no operator" case is |
50 |
> > wrong for many real situations. You can assume either "any slot" or |
51 |
> > "best slot", both of which will allow packages to be removed |
52 |
> > unsafely, or you can assume "all slots", which is excessively |
53 |
> > paranoid for many packages. |
54 |
> > |
55 |
> Do you see a way for the PM to decide which behavior it should use on |
56 |
> per case basis? |
57 |
|
58 |
The package mangler has to be told explicitly. It can't work it out |
59 |
itself. |
60 |
|
61 |
> If yes, than having both operators makes sense. |
62 |
> If no, the PM has to decide on one of the behaviors anyways. Why not |
63 |
> specify which one that is (see above)? |
64 |
|
65 |
Having both operators provides a way of checking that developers have |
66 |
explicitly confirmed which behaviour they mean. Without them, we don't |
67 |
know whether no operator means "whichever default we decide", or |
68 |
whether it means "I didn't realise that this dep has slots now". |
69 |
|
70 |
-- |
71 |
Ciaran McCreesh |