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 09:12:21
Message-Id: 20110701100931.29650d1e@googlemail.com
In Reply to: Re: [gentoo-pms] Do we want an EAPI 5? by Sebastian Luther
1 On Fri, 01 Jul 2011 10:54:59 +0200
2 Sebastian Luther <SebastianLuther@×××.de> wrote:
3 > > Anyone not following the policy is already breaking things, and we
4 > > can't switch to the "use the tree ebuild" behaviour since it doesn't
5 > > work when ebuilds get removed. All we're doing is making an existing
6 > > bug more visible.
7 >
8 > The "make the bug more visible part" is what I'm up to.
9
10 A bug is a bug, even if people don't see it very frequently. Making
11 bugs visible is a *good* thing, since it means they're easier to
12 identify and fix.
13
14 > > It's not worth it. It's a huge amount of work to summarise every
15 > > incorrect argument and false lead. It's not done by official
16 > > standards bodies, who have far more resources than we do, so what
17 > > you're asking for is just obstructionism and red tape.
18 >
19 > I'm not asking for a summary of everything someone said about the
20 > topic. I'm asking for something between this and a PMS text, simply
21 > put, the stuff that is mandated by the glep rules.
22
23 Too much work. You're welcome to do it if you think it's necessary, but
24 Gentoo doesn't have the manpower to hold everything up for someone to
25 copy a bunch of largely irrelevant discussion into a document for every
26 little thing. The spec describes how it works; all the false starts are
27 no longer an issue.
28
29 > >> Or you do it like portage does it and assume the package works with
30 > >> any slot (the :* case) and if it doesn't, declare that a bug of the
31 > >> package. Now giving ebuild devs the := operator allows them to say
32 > >> "the package insist on the slot it was build against".
33 > >
34 > > Can't. Right now there's no way for packages to specify those kinds
35 > > of dependencies correctly. Assuming :* just isn't safe, and doesn't
36 > > match the historical meaning of lack-of-slot dependencies.
37 > >
38 > I don't know what you mean with historical meaning. As long as I use
39 > gentoo (since ~mid 2007) it has been that way. I agree that it isn't
40 > safe, but that's how portage does it.
41
42 Portage has never done full safety checking or purges, though -- partly
43 because doing so right now requires either being excessively paranoid
44 or not catching most unsafe operations.
45
46 > For EAPI5, there is the possibility to make this the default and leave
47 > := for the cases that don't behave this way (see below).
48
49 But then we won't know whether people really mean that (they usually
50 don't) or whether they just forgot. Given that developers aren't in the
51 habit of giving the least bit of thought to slots, we need a way for
52 repoman to know whether or not it needs to tell developers to pay
53 attention. Slot operator dependencies are most useful when they're
54 widely used.
55
56 > The latter has the advantage that it's simpler in the sense that it
57 > introduces only one new thing (the := operator) to do one new thing,
58 > namely to turn the :* behavior most people (those that use portage)
59 > are used to into the := behavior. It also doesn't leave any
60 > uncertainty about what the "no-operator" case means.
61
62 There's no uncertainty with the "no operator" case with the
63 Council-approved version either -- it means the developer has forgotten
64 to specify a behaviour, so the package manager should be paranoid and
65 assume it matches *all* slots since it can't prove that it doesn't.
66 That's not what Portage does currently; Portage's current behaviour
67 isn't strong enough to provide useful protection.
68
69 In any case, this is all rehashing existing discussion.
70
71 --
72 Ciaran McCreesh

Attachments

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