1 |
Am 01.07.2011 08:12, schrieb Ciaran McCreesh: |
2 |
> On Thu, 30 Jun 2011 20:48:46 +0200 |
3 |
> Sebastian Luther <SebastianLuther@×××.de> wrote: |
4 |
>>> Portage's behaviour is already broken there -- think what happens |
5 |
>>> when ebuilds get removed. |
6 |
>> |
7 |
>> I know. I'm not opposed to this change, but the needed work flow |
8 |
>> change for ebuild devs has to be communicated. |
9 |
> |
10 |
> Shouldn't be a workflow change. It's already policy to do a revbump if |
11 |
> dependencies change. |
12 |
> |
13 |
|
14 |
It is policy, but as you're probably aware of, it's not followed in may |
15 |
cases, which in turn raises the question if people wouldn't prefer to |
16 |
change the policy instead of their work flow (not that I would suggest |
17 |
that). |
18 |
Someone needs to ask them if you want that in EAPI5. |
19 |
|
20 |
>>>> Could you please give a summary (or point me to one) of the |
21 |
>>>> discussion about :=/:*? |
22 |
>>> |
23 |
>>> See the original EAPI 3 discussion. It's all there. |
24 |
>>> |
25 |
>> Yeah, the whole discussion is there, but not a summary. I don't have |
26 |
>> the time to wade through all these mails. |
27 |
> |
28 |
> Part of the reason EAPI 3 dragged on for so long was that rather than |
29 |
> reading the discussion, people would say "I've not read the entire |
30 |
> thread, but it seems to me that ...", and then the entire discussion |
31 |
> would have to be repeated all over again. |
32 |
|
33 |
I think part of the problem here is that those things aren't written |
34 |
down as a glep (or some similar document). Imo every change that leads |
35 |
to a non trivial amount of discussion should be written down in such a |
36 |
way. Otherwise it's hard for people that missed the original discussion |
37 |
to catch up and those that took part in this discussion get frustrated |
38 |
because they have to repeat themselves again and again. |
39 |
This should be discussed in another thread if someone is interested. |
40 |
|
41 |
> |
42 |
> If you're just looking for a summary, not details: say a user has |
43 |
> cat/dep:1, cat/dep:2 and cat/dep:3 installed, and wants to uninstall |
44 |
> cat/dep:1 and cat/dep:2. Say there's cat/pkg installed which has a dep |
45 |
> upon cat/dep. Then there's no way for the package mangler to know |
46 |
> which cat/dep slots are still 'needed', and which can be safely |
47 |
> removed. Thus, to be safe, it has to assume that all three slots might |
48 |
> be needed. |
49 |
> |
50 |
Or you do it like portage does it and assume the package works with any |
51 |
slot (the :* case) and if it doesn't, declare that a bug of the package. |
52 |
Now giving ebuild devs the := operator allows them to say "the package |
53 |
insist on the slot it was build against". |
54 |
|
55 |
> Nearly all packages that dep upon a slotted dependent have one of two |
56 |
> behaviours: they're ok with any slot that matches the rest of the spec |
57 |
> (including switching at runtime), or they need the best slot that was |
58 |
> present at install time. The former is :*, the latter :=. |
59 |
> |
60 |
> There are a few perverse cases that don't fit these. Those need special |
61 |
> fancy handling, and they're sufficiently fiddly that we shouldn't be |
62 |
> holding up solving the large number easy cases to deal with one or two |
63 |
> weird packages. |
64 |
> |
65 |
Agreed. |
66 |
|
67 |
>> Isn't it desirable that different PMs handle the "no operator" case in |
68 |
>> the same way (independently of the question of having one or both |
69 |
>> operators available)? |
70 |
> |
71 |
> The problem is that every way of handling the "no operator" case is |
72 |
> wrong for many real situations. You can assume either "any slot" or |
73 |
> "best slot", both of which will allow packages to be removed unsafely, |
74 |
> or you can assume "all slots", which is excessively paranoid for many |
75 |
> packages. |
76 |
> |
77 |
Do you see a way for the PM to decide which behavior it should use on |
78 |
per case basis? |
79 |
If yes, than having both operators makes sense. |
80 |
If no, the PM has to decide on one of the behaviors anyways. Why not |
81 |
specify which one that is (see above)? |