Re: [gentoo-dev] explicit -r0 in ebuild filename

[Brian Harring]

On Sun, Mar 30, 2008 at 04:20:57AM +0100, Ciaran McCreesh wrote:
> On Sat, 29 Mar 2008 20:12:37 -0700
> Brian Harring <ferringb@×××××.com> wrote:
> > What this email is about is the inconsistancy allowed on disk and the
> > fact explicitly leaving -r0 out of on disk name thus far seems to be
> > an unofficial gentoo-x86 standard.
>
> Which means it's not something to be specified in PMS. Devmanual,
> possibly, but that's a whole different kettle of fish. (We don't
> specify that you should use tabs for indenting in ebuilds in PMS
> either.)

Contrasting tabs vs spaces is a whole other matter.  One of the things 
you attempted to do in splitting PMS was to force certain technical 
tweaks through because frankly, they made sense (or you were stubborn, 
and it mostly made sense).  That's fine.

Bearing that in mind, there is no reason to have a format definition 
for ebuild trees and to leave gotchas in it where they can be easily 
addressed via simple bannination rules.


> > > Uniquely indentifying an ebuild is an issue regardless of whether or
> > > not -r0 is allowed. See PMS section 2.4.
> >
> > Stating that each cpv in a repo must be unique ignores that there are
> > multiple ways to specify certain cpv's due to implicit 0 (both suffix
> > and rev).  Frankly it's pretty stupid to state "it must be unique"
> > while allowing multiple ways for people to screw up and violate that
> > constraint.
> >
> > Intentionally allowing gotchas is dumb behaviour- removal of the
> > gotcha is the intention here.
>
> PMS is going with the tree here. There have always been equivalent but
> not equal ways of specifying versions, and people use them.

Thing is, people *don't*.  This is the first time in my experience 
gentoo wise seeing a -r0 on disk (not rhetoric, literally the truth).  
Checking the tree for suffixes, specifically for explicit on disk 0 
(_alpha0 for example):

_alpha: 1 out of 82, ~1.2%
 dev-util/cssc-0.15_alpha0  (user address, 'bruce locke'; 2003)

_beta: 1 out of 255, ~.3%
 dev-python/visual-4_beta0  (tercel)

_pre: 4 out of 278, ~1.4%
 games-board/gtkboard-0.11_pre0      (msterret- bones?, 2003)
 media-sound/cdparanoia-3.10_pre0-r1 (drac)
 media-sound/cdparanoia-3.10_pre0    (drac)
 dev-util/larch-1.0_pre0             (rphillips, 2003)

_rc: 2 out of 197, ~1%
 www-client/elinks-0.11.4_rc0    (spock)
 dev-haskell/hs-plugins-1.0_rc0  (araujo)

_p: 7 out of 329, ~2.1%
 sys-fs/owfs-2.7_p0-r2  (wschlich)
 sys-fs/owfs-2.7_p0     (wschlich)
 sys-fs/owfs-2.7_p0-r1  (wschlich)
 app-cdr/dvd95-1.2_p0   (pylon)
 app-cdr/dvd95-1.3_p0   (pylon)
 media-fonts/wqy-bitmapfont-0.9.9_p0 (matsuu)
 net-misc/ntp-4.2.4_p0  (vapier, aka the spankster)

Fairly obvious, the suffix0 case is pretty rarely used.  Quick look 
at the commiters behind the explict 0 suffixes, you don't  see any 
maintainer actually repeat it in another pkg- personally, I suspect 
majority of it was new dev mistake, in some cases propagated (wschlich 
feel free to correct me on this sine you've got the most there).  For 
dvd95, well aware pylon wasn't new at that point, so theory doesn't 
quite hold there (although oversight may fly).

Of the ones above, only one I even vaguely recall a reason being given 
for suffix0 was ntp- mirroring upstream versioning roughly (vapier, 
please correct me if I'm wrong).  Beneficial perhaps, but one single 
"yeah that's slightly nicer" case doesn't mean it's best for the 
majority.


> You don't  want to start breaking people who use >=..._alpha0 when
> the version in the tree uses plain _alpha, for example.

Explicitly requiring on disk to not specify implicit components in no 
way breaks atom support, or anything else for that matter.  Either 
this is a minor brain fart on your part, or again, you're going to 
have to be a fair bit more clear in your explanation.


> Package managers have to deal  with this kind of thing, and it's
> not one of those areas where we can change reality with little or
> no impact.

While package managers have to deal with this, there are two strong 
args for forcing such a change into the repo itself;

1) it is a far simpler rule for devs to keep straight, and for 
managers to track for violations.  Instead of checking for 1.0 when 
1.0-r0 is found, seeing 1.0-r0 is an error.  Clear, concise, simple; 
meaning folks are less likely to screw it up.

2) not surprisingly, it actually simplifies manager implementation.  
Tracking internally whether 1.0 is actually 1.0-r0 on disk or not 
means extra level of mappings required, meaning more areas to screw it 
up.

Basically, this particular problem has always been a thorn; I may be 
missing something, but I've yet to see any strong scenarios for why 
this gotcha should be allowed to exist on disk- adding explicit rules 
blocking it in the ondisk format itself has several benefits as laid 
out above, and is already pretty much the unofficial policy standard.

Essentially, the "we don't mandate policy in PMS" is ignoring the 
technical benefits of doing this- provide a technical reason against 
it, and I'd be game.  That said, calling it policy when it's a dumb 
gotcha that has benefits for elimination is ducking the issue imo.

~harring