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 |