1 |
On Mon, Mar 31, 2008 at 01:06:02AM +0100, Ciaran McCreesh wrote: |
2 |
> On Sun, 30 Mar 2008 17:02:16 -0700 |
3 |
> Brian Harring <ferringb@×××××.com> wrote: |
4 |
> > > But the PV does. |
5 |
> > |
6 |
> > PV varying first of all, isn't incredibly grand from where I'm |
7 |
> > sitting- yet more any versionator style code has to account for. |
8 |
> > Second, so what? We're talking about 15 ebuilds here. It's not as |
9 |
> > though the ebuilds are completely screwed in this- dealing with the |
10 |
> > PV change for the ebuild is pretty minor. |
11 |
> |
12 |
> But pointless, since it gives no advantage. If there were something to |
13 |
> be gained from what you're proposing then maybe fifteen ebuilds |
14 |
> wouldn't be so big a deal, but there isn't. |
15 |
|
16 |
Conversation is going pretty cyclical, so unless *new* points are |
17 |
brought up, I'll be waiting for new commentary. |
18 |
|
19 |
Going to reiterate this one more time; the proposal is simple enough; |
20 |
if it's an implicit 0 via cpv parsing, it should *not* be explicitly |
21 |
specified on disk. 'diffball-1.0_alpha0.ebuild' can just as easily be |
22 |
specified as 'diffball-1.0_alpha.ebuild', 'diffball-1.0-r0.ebuild' can |
23 |
just as easily be specified as 'diffball-1.0.ebuild'. |
24 |
|
25 |
Reiterating the gain: consistancy on disk, consistancy in dealing with |
26 |
PV/PVR. As you keep point out, PV does vary- having the results of |
27 |
ebuild execution change depending on whether or not you name your |
28 |
ebuild 'diffball-1.0_alpha0.ebuild' or 'diffball-1.0_alpha.ebuild' is |
29 |
*not* a feature, it is what you would classically call a "design |
30 |
misfeature". PVR for 'diffball-1.0-r0.ebuild' being '1.0' instead of |
31 |
'1.0-r0' is yet another argument for punting explicit -r0 on disk- |
32 |
it's a gotcha, design flaw in the format. |
33 |
|
34 |
It's a simple tweak, with no real loss of functionality (lots of |
35 |
claims, no single hard proof thus far). As spanky has stated, there |
36 |
*is* a loss of ease of use in a small subset of ebuilds- worst case, |
37 |
.06% ebuilds. Personally, I don't consider that minority worth |
38 |
preserving since preserving that means leaving open several gotchas in |
39 |
ebuild writing, and complicates interactions (both pm and dev). |
40 |
|
41 |
So... there it is. Would be rather nice to have ebuild devs weight in |
42 |
on this one, rather then just package manager monkeys also (they're |
43 |
the ones bound most by the change after all). Laid out the advantages |
44 |
to this- kindly lay out the disadvantages, where this makes things |
45 |
worse if you're looking for a response. |
46 |
|
47 |
~harring |