[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] explicit -r0 in ebuild filename
From:       Brian Harring <ferringb () gmail ! com>
Date:       2008-03-31 0:29:10
Message-ID: 20080331002910.GD9305 () seldon ! hsd1 ! ca ! comcast ! net
[Download RAW message or body]

On Mon, Mar 31, 2008 at 01:06:02AM +0100, Ciaran McCreesh wrote:
> On Sun, 30 Mar 2008 17:02:16 -0700
> Brian Harring <ferringb@gmail.com> wrote:
> > > But the PV does.
> > 
> > PV varying first of all, isn't incredibly grand from where I'm 
> > sitting- yet more any versionator style code has to account for.  
> > Second, so what?  We're talking about 15 ebuilds here.  It's not as 
> > though the ebuilds are completely screwed in this- dealing with the
> > PV change for the ebuild is pretty minor.
> 
> But pointless, since it gives no advantage. If there were something to
> be gained from what you're proposing then maybe fifteen ebuilds
> wouldn't be so big a deal, but there isn't.

Conversation is going pretty cyclical, so unless *new* points are 
brought up, I'll be waiting for new commentary.

Going to reiterate this one more time; the proposal is simple enough; 
if it's an implicit 0 via cpv parsing, it should *not* be explicitly 
specified on disk.  'diffball-1.0_alpha0.ebuild' can just as easily be 
specified as 'diffball-1.0_alpha.ebuild', 'diffball-1.0-r0.ebuild' can 
just as easily be specified as 'diffball-1.0.ebuild'.

Reiterating the gain: consistancy on disk, consistancy in dealing with 
PV/PVR.  As you keep point out, PV does vary- having the results of 
ebuild execution change depending on whether or not you name your 
ebuild 'diffball-1.0_alpha0.ebuild' or 'diffball-1.0_alpha.ebuild' is 
*not* a feature, it is what you would classically call a "design 
misfeature".  PVR for 'diffball-1.0-r0.ebuild' being '1.0' instead of 
'1.0-r0' is yet another argument for punting explicit -r0 on disk- 
it's a gotcha, design flaw in the format.

It's a simple tweak, with no real loss of functionality (lots of 
claims, no single hard proof thus far).  As spanky has stated, there 
*is* a loss of ease of use in a small subset of ebuilds- worst case, 
.06% ebuilds.  Personally, I don't consider that minority worth 
preserving since preserving that means leaving open several gotchas in 
ebuild writing, and complicates interactions (both pm and dev).

So... there it is.  Would be rather nice to have ebuild devs weight in 
on this one, rather then just package manager monkeys also (they're 
the ones bound most by the change after all).  Laid out the advantages 
to this- kindly lay out the disadvantages, where this makes things 
worse if you're looking for a response.

~harring

[Attachment #3 (application/pgp-signature)]
-- 
gentoo-dev@lists.gentoo.org mailing list


[prev in list] [next in list] [prev in thread] [next in thread]