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

[Ciaran McCreesh]

On Sun, 30 Mar 2008 02:39:46 -0700
Brian Harring <ferringb@×××××.com> wrote:
> I'm unaware of any suffix *currently* that has some long time usage that
> is used by a mere .06% of the tree.  LZMA likely would apply, but
> that also was introduced rather recent so isn't exactly
> representative.

7z.

> Finally, drawing parallels between unpack and forcing a specific form
> of suffix makes no sense- dropping a format from unpack has real
> world consequences, specifically breakage.  Forcing "one or the
> other" suffix wise is a quick inspection of 15 ebuilds in gentoo-x86,
> and minor compat code if the package manager upstream wants to be
> friendly to the minority of users it may affect if they make suffix0
> an error when dealing with vdb.

Getting fifteen ebuilds changed might be something you could get done
via QA, but it's not PMS's job.

(Unless it's something really annoying, of course...)

> There are lots of things that upstream does with versioning that
> doesn't map perfectly into ebuild versioning scheme- and that's
> actually quite fine.

Sure, but arbitrarily banning even more of them is wrong.

> Besides, this discussion is *not* about banning _pre0, or _alpha0-
> it's about banning explicit usage of implicit version components in
> the on disk ebuild.
>
> Phrasing another way, it's pointless to have
> dev-util/diffball/diffball-1.0_alpha0.ebuild ;
> dev-util/diffball/diffball-1.0_alpha.ebuild
>
> is the exact same version.

But a different PV.

> Banning _suffix0 (and -r0) loses nothing,  but gains consistancy in
> on disk naming (thus less likely for devs to screw up as occured
> today), and simplifies working with ebuilds on disk for managers/repo
> modifiers.

And means people need to start using versionator.

> > Introducing multiple sets of versioning rules is a far worse gotcha
> > than a ban on duplicates. Banning _alpha etc in some places but not
> > others gets very confusing very quickly.
>
> You're reaching.  Nothing is lost here.  What you're arguing for is
> thus-
>
> "you can have name the ebuild either pkg-1.0_alpha0.ebuild, or
> pkg-1.0_alpha.ebuild.  You must not have both on disk however"
>
> versus
>
> "you must name the ebuild pkg-1.0_alpha.ebuild."
>
> There is no "multiple sets of versioning rules" here, the versioning
> rules stay *exactly* the same.  All that's being done is that the
> unique cpv constraint is pushed down to the on disk repository level,
> thus removing the issue permenentaly (while increasing consistancy
> across repos).

But you're not pushing a unique CPV constraint unless you start banning
all sorts of other things.

> As I've done in attempting to respond to your
> questions/counterargument, please site examples/data, or at the very
> least be explicit about what you're claiming.  I know the versioning
> rules (unfortunately) quite well, and there is no 'multiple sets'
> introduced via this change- so either you're confused, or you see
> something I don't.
>
> Saves both of us a lot of time if you're explicit.

You're talking about forcing one lot of rules for on-disk packages and
another lot of rules for versions in general.

> > The package manager has to deal with equality and equivalence
> > separately anyway... If you're storing 1.0 when the actual version
> > is 1.0-r0 you have issues regardless of whether -r0 itself is
> > banned on disk
>
> You're pretty clearly missing the point.  When I state "it makes
> repository/package manager operations simpler", this is a classic
> example- you don't have to worry about whether or not it was -r0 on
> disk, or was revisionless.  Via forcing consistancy into the spec,
> you force it to be one or the other.

No! Even ignoring -r0, you still have to know whether it's 010 or 10 on
disk. Or do you want to ban that too? And all the other possible ways
of having multiple equivalent but non-equal versions?

> >  -- if you want to prevent that, you have to start banning versions
> > like 086 and 1.00 too.
>
> No need to ban 1.00; it's already banned by PMS- quoting from
> names.tex:
>
> A version starts with the number part, which is in the form
> \t{[0-9]+($\backslash$.[0-9]+)*} (a positive
> integer, followed by zero or more dot-prefixed positive integers).
>
> Note the 'positive integers'; so 1.00 is actually blocked by PMS.
> That said, that same text seems to invalidly ban 1.0 also.

Zero is a positive integer! We'd've said 'natural' if we wanted to ban
zero... Having said that, send a patch if you think we should cater to
people using other definitions.

-- 
Ciaran McCreesh