Gentoo Archives: gentoo-pms

From: Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>
To: gentoo-pms@l.g.o
Subject: Re: [gentoo-pms] Do we want an EAPI 5?
Date: Fri, 01 Jul 2011 08:11:58
Message-Id: 20110701090908.7804e653@googlemail.com
In Reply to: Re: [gentoo-pms] Do we want an EAPI 5? by Sebastian Luther
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

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies

Subject Author
Re: [gentoo-pms] Do we want an EAPI 5? Sebastian Luther <SebastianLuther@×××.de>