Gentoo Archives: gentoo-pms

From: Sebastian Luther <SebastianLuther@×××.de>
To: gentoo-pms@l.g.o
Subject: Re: [gentoo-pms] Do we want an EAPI 5?
Date: Fri, 01 Jul 2011 08:56:05
In Reply to: Re: [gentoo-pms] Do we want an EAPI 5? by Ciaran McCreesh
Am 01.07.2011 10:09, schrieb Ciaran McCreesh:
> On Fri, 01 Jul 2011 09:45:34 +0200 > Sebastian Luther <SebastianLuther@×××.de> 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 > itself. > >> 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.


Subject Author
Re: [gentoo-pms] Do we want an EAPI 5? Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>