Am 01.07.2011 10:09, schrieb Ciaran McCreesh:
> On Fri, 01 Jul 2011 09:45:34 +0200
> Sebastian Luther <SebastianLuther@...> wrote:
>>>> I know. I'm not opposed to this change, but the needed work flow
>>>> change for ebuild devs has to be communicated.
>>> Shouldn't be a workflow change. It's already policy to do a revbump
>>> if dependencies change.
>> It is policy, but as you're probably aware of, it's not followed in
>> may cases, which in turn raises the question if people wouldn't
>> prefer to change the policy instead of their work flow (not that I
>> would suggest that).
> Anyone not following the policy is already breaking things, and we
> can't switch to the "use the tree ebuild" behaviour since it doesn't
> work when ebuilds get removed. All we're doing is making an existing
> bug more visible.
The "make the bug more visible part" is what I'm up to.
>> I think part of the problem here is that those things aren't written
>> down as a glep (or some similar document). Imo every change that leads
>> to a non trivial amount of discussion should be written down in such a
>> way. Otherwise it's hard for people that missed the original
>> discussion to catch up and those that took part in this discussion
>> get frustrated because they have to repeat themselves again and again.
>> This should be discussed in another thread if someone is interested.
> It's not worth it. It's a huge amount of work to summarise every
> incorrect argument and false lead. It's not done by official standards
> bodies, who have far more resources than we do, so what you're asking
> for is just obstructionism and red tape.
I'm not asking for a summary of everything someone said about the topic.
I'm asking for something between this and a PMS text, simply put, the
stuff that is mandated by the glep rules.
>>> If you're just looking for a summary, not details: say a user has
>>> cat/dep:1, cat/dep:2 and cat/dep:3 installed, and wants to uninstall
>>> cat/dep:1 and cat/dep:2. Say there's cat/pkg installed which has a
>>> dep upon cat/dep. Then there's no way for the package mangler to
>>> know which cat/dep slots are still 'needed', and which can be safely
>>> removed. Thus, to be safe, it has to assume that all three slots
>>> might be needed.
>> Or you do it like portage does it and assume the package works with
>> any slot (the :* case) and if it doesn't, declare that a bug of the
>> package. Now giving ebuild devs the := operator allows them to say
>> "the package insist on the slot it was build against".
> Can't. Right now there's no way for packages to specify those kinds of
> dependencies correctly. Assuming :* just isn't safe, and doesn't match
> the historical meaning of lack-of-slot dependencies.
I don't know what you mean with historical meaning. As long as I use
gentoo (since ~mid 2007) it has been that way. I agree that it isn't
safe, but that's how portage does it.
For EAPI5, there is the possibility to make this the default and leave
:= for the cases that don't behave this way (see below).
>>> The problem is that every way of handling the "no operator" case is
>>> wrong for many real situations. You can assume either "any slot" or
>>> "best slot", both of which will allow packages to be removed
>>> unsafely, or you can assume "all slots", which is excessively
>>> paranoid for many packages.
>> Do you see a way for the PM to decide which behavior it should use on
>> per case basis?
> The package mangler has to be told explicitly. It can't work it out
>> If yes, than having both operators makes sense.
>> If no, the PM has to decide on one of the behaviors anyways. Why not
>> specify which one that is (see above)?
> Having both operators provides a way of checking that developers have
> explicitly confirmed which behaviour they mean. Without them, we don't
> know whether no operator means "whichever default we decide", or
> whether it means "I didn't realise that this dep has slots now".
Right, that's lost when a default is selected.
It now boils down to the question what people want.
a) The proposal that had been voted into EAPI3.
b) What I said above.
The first having the advantage that it's possible to check if a dep has
been updated to slot deps or not.
The latter has the advantage that it's simpler in the sense that it
introduces only one new thing (the := operator) to do one new thing,
namely to turn the :* behavior most people (those that use portage) are
used to into the := behavior. It also doesn't leave any uncertainty
about what the "no-operator" case means.