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