1 |
On Sun, Mar 30, 2008 at 05:40:44AM +0100, Ciaran McCreesh wrote: |
2 |
> On Sat, 29 Mar 2008 21:16:51 -0700 |
3 |
> Brian Harring <ferringb@×××××.com> wrote: |
4 |
> > Contrasting tabs vs spaces is a whole other matter. One of the |
5 |
> > things you attempted to do in splitting PMS was to force certain |
6 |
> > technical tweaks through because frankly, they made sense (or you |
7 |
> > were stubborn, and it mostly made sense). That's fine. |
8 |
> |
9 |
> Not where those things involve large tree changes... |
10 |
> |
11 |
> > Fairly obvious, the suffix0 case is pretty rarely used. |
12 |
> |
13 |
> It's used more than a lot of other things... Some file suffixes for |
14 |
> unpack are only used by a single package, for example, yet they're |
15 |
> still in there. Ditto for some of the utilities. |
16 |
|
17 |
This isn't relevant to the discussion at hand; besides, I'm |
18 |
unaware of any suffix *currently* that has some long time usage that |
19 |
is used by a mere .06% of the tree. LZMA likely would apply, but that |
20 |
also was introduced rather recent so isn't exactly representative. |
21 |
|
22 |
Finally, drawing parallels between unpack and forcing a specific form |
23 |
of suffix makes no sense- dropping a format from unpack has real world |
24 |
consequences, specifically breakage. Forcing "one or the other" |
25 |
suffix wise is a quick inspection of 15 ebuilds in gentoo-x86, and |
26 |
minor compat code if the package manager upstream wants to be friendly |
27 |
to the minority of users it may affect if they make suffix0 an error |
28 |
when dealing with vdb. |
29 |
|
30 |
|
31 |
> > Quick look at the commiters behind the explict 0 suffixes, you |
32 |
> > don't see any maintainer actually repeat it in another pkg- |
33 |
> > personally, I suspect majority of it was new dev mistake, in some |
34 |
> > cases propagated (wschlich feel free to correct me on this sine |
35 |
> > you've got the most there). For dvd95, well aware pylon wasn't new |
36 |
> > at that point, so theory doesn't quite hold there (although oversight |
37 |
> > may fly). |
38 |
> |
39 |
> Doesn't follow. Most upstreams don't use versions that fit an |
40 |
> unversioned part most of the time. You wouldn't expect to see it |
41 |
> repeated all over the place because in the real world it's not a very |
42 |
> common (but importantly, not non-existent or massively rare) issue. |
43 |
|
44 |
There are lots of things that upstream does with versioning that |
45 |
doesn't map perfectly into ebuild versioning scheme- and that's |
46 |
actually quite fine. |
47 |
|
48 |
Besides, this discussion is *not* about banning _pre0, or _alpha0- |
49 |
it's about banning explicit usage of implicit version components in |
50 |
the on disk ebuild. |
51 |
|
52 |
Phrasing another way, it's pointless to have |
53 |
dev-util/diffball/diffball-1.0_alpha0.ebuild ; |
54 |
dev-util/diffball/diffball-1.0_alpha.ebuild |
55 |
|
56 |
is the exact same version. Banning _suffix0 (and -r0) loses nothing, |
57 |
but gains consistancy in on disk naming (thus less likely for devs to |
58 |
screw up as occured today), and simplifies working with ebuilds on |
59 |
disk for managers/repo modifiers. |
60 |
|
61 |
|
62 |
> > > You don't want to start breaking people who use >=..._alpha0 when |
63 |
> > > the version in the tree uses plain _alpha, for example. |
64 |
> > |
65 |
> > Explicitly requiring on disk to not specify implicit components in no |
66 |
> > way breaks atom support, or anything else for that matter. Either |
67 |
> > this is a minor brain fart on your part, or again, you're going to |
68 |
> > have to be a fair bit more clear in your explanation. |
69 |
> |
70 |
> Introducing multiple sets of versioning rules is a far worse gotcha |
71 |
> than a ban on duplicates. Banning _alpha etc in some places but not |
72 |
> others gets very confusing very quickly. |
73 |
|
74 |
You're reaching. Nothing is lost here. What you're arguing for is |
75 |
thus- |
76 |
|
77 |
"you can have name the ebuild either pkg-1.0_alpha0.ebuild, or |
78 |
pkg-1.0_alpha.ebuild. You must not have both on disk however" |
79 |
|
80 |
versus |
81 |
|
82 |
"you must name the ebuild pkg-1.0_alpha.ebuild." |
83 |
|
84 |
There is no "multiple sets of versioning rules" here, the versioning |
85 |
rules stay *exactly* the same. All that's being done is that the |
86 |
unique cpv constraint is pushed down to the on disk repository level, |
87 |
thus removing the issue permenentaly (while increasing consistancy |
88 |
across repos). |
89 |
|
90 |
As I've done in attempting to respond to your |
91 |
questions/counterargument, please site examples/data, or at the very |
92 |
least be explicit about what you're claiming. I know the versioning |
93 |
rules (unfortunately) quite well, and there is no 'multiple sets' |
94 |
introduced via this change- so either you're confused, or you see |
95 |
something I don't. |
96 |
|
97 |
Saves both of us a lot of time if you're explicit. |
98 |
|
99 |
|
100 |
> Repositories are already not allowed to contain duplicated versions. |
101 |
> That's a sufficiently strong guarantee. |
102 |
> |
103 |
> > 2) not surprisingly, it actually simplifies manager implementation. |
104 |
> > Tracking internally whether 1.0 is actually 1.0-r0 on disk or not |
105 |
> > means extra level of mappings required, meaning more areas to screw |
106 |
> > it up. |
107 |
> |
108 |
> The package manager has to deal with equality and equivalence |
109 |
> separately anyway... If you're storing 1.0 when the actual version is |
110 |
> 1.0-r0 you have issues regardless of whether -r0 itself is banned on |
111 |
> disk |
112 |
|
113 |
You're pretty clearly missing the point. When I state "it makes |
114 |
repository/package manager operations simpler", this is a classic |
115 |
example- you don't have to worry about whether or not it was -r0 on |
116 |
disk, or was revisionless. Via forcing consistancy into the spec, you |
117 |
force it to be one or the other. |
118 |
|
119 |
There are other examples that come up from this, but you pointed out |
120 |
one of the simpler ones above that actually argue *for* the change I'm |
121 |
requesting. |
122 |
|
123 |
|
124 |
> -- if you want to prevent that, you have to start banning versions |
125 |
> like 086 and 1.00 too. |
126 |
|
127 |
No need to ban 1.00; it's already banned by PMS- quoting from |
128 |
names.tex: |
129 |
|
130 |
A version starts with the number part, which is in the form |
131 |
\t{[0-9]+($\backslash$.[0-9]+)*} (a positive |
132 |
integer, followed by zero or more dot-prefixed positive integers). |
133 |
|
134 |
Note the 'positive integers'; so 1.00 is actually blocked by PMS. |
135 |
That said, that same text seems to invalidly ban 1.0 also. |
136 |
|
137 |
~harring |