Gentoo Archives: gentoo-project

From: Brian Harring <ferringb@×××××.com>
To: gentoo-project@l.g.o
Subject: Re: [gentoo-project] Call for agenda items -- Council meeting 09-10-2012
Date: Fri, 28 Sep 2012 00:02:04
Message-Id: 20120927221336.GB9751@localhost
In Reply to: Re: [gentoo-project] Call for agenda items -- Council meeting 09-10-2012 by Ulrich Mueller
1 On Thu, Sep 27, 2012 at 08:19:13AM +0200, Ulrich Mueller wrote:
2 > >>>>> On Tue, 25 Sep 2012, Ulrich Mueller wrote:
3 >
4 > > - Package names:
5 > > Our current spec forbids that package names "end in a hyphen
6 > > followed by one or more digits". This isn't consequent, since it
7 > > still allows PN to be e.g. "foo-1a" which looks like a valid PF.
8 > > OTOH, there's no technical reason for this limitation (backwards
9 > > compatibility issues taken aside).
10 > > Since this issue is open since more than five years, I believe that
11 > > it's time to ask the council for guidance in what direction we
12 > > should go:
13 > > a) Drop the limitation entirely (possibly in a future EAPI).
14 > > b) Make it stricter, i.e. disallow package names ending in a
15 > > hyphen followed by anything that looks like a valid PVR.
16 > > This is current Portage behaviour, and the tree complies with
17 > > it, too.
18 > > c) Leave the spec as it is (and make Portage comply with it).
19 > > See bug 174536 for details.
20 >
21 > Actually, there's also:
22 > d) Require a) for Package managers and b) by tree policy
23 > (Postel's Law, brought up by mgorny). Practically, this would
24 > mean that repoman would reject "foo-1" as package name, but the
25 > rest of Portage would accept it.
26
27 Grr. And people wonder why I get brutally blunt at times.
28
29 This restriction, whether people like it or not, is encoded into
30 some fairly core places that have consequences. You do this, you
31 break all existing managers that see it in the vdb. Not "oh looky, a
32 warning, isn't that cute by mildly annoying", break.
33
34 Badly. Break. PM shats the bed, traceback gets thrown.
35
36 Considering managers do full graphs, that node gets touched, the
37 affected PM isn't going to be able to even upgrade it's way out of it-
38 best case, if it's implemented sanely a --nodeps will avoid that node.
39 However a lot of PMs still have legacy virtuals code, meaning if that
40 cache is stale, looky looky, the vdb gets walked and you get a 'boom'.
41
42 This isn't even commenting on binpkgs, which is where you're likely to
43 see older managers existing as clients.
44
45 All of that is unversioned. We cannot hide this sort of change- at
46 best we can deploy it, force all QA tools to block it for N years,
47 than allow it in; anything else is risking known (yes known, people
48 have been pointing this out for ages).
49
50 What for? So someone can name their package foo-1? Is that really
51 such a major gap we're willing to induce breakage?
52
53 Will anyone even !@#*ing use a package names foo-1? I've yet to see
54 an example given, just ignoring of the breakage it will induce.
55
56 Honestly, you want to push it, you address how this isn't going to
57 break things, lay out the timelines, identifying when we willingly
58 switchover to breaking managers older than a certain date. It does
59 not get pushed up to the council w/out the negatives/flaws mentioned.
60
61 Shorter version; you very clearly left out option C; "leave it as is
62 since PMS is filled with warts, this isn't hurting anything, and
63 changing it will break things."
64
65 ~harring

Replies