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

[Ciaran McCreesh]

On Sat, 29 Mar 2008 21:16:51 -0700
Brian Harring <ferringb@×××××.com> wrote:
> 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.

Not where those things involve large tree changes...

> Fairly obvious, the suffix0 case is pretty rarely used.

It's used more than a lot of other things... Some file suffixes for
unpack are only used by a single package, for example, yet they're
still in there. Ditto for some of the utilities.

> 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).

Doesn't follow. Most upstreams don't use versions that fit an
unversioned part most of the time. You wouldn't expect to see it
repeated all over the place because in the real world it's not a very
common (but importantly, not non-existent or massively rare) issue.

> > 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.

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.

> > 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;

Repositories are already not allowed to contain duplicated versions.
That's a sufficiently strong guarantee.

> 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.

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 -- if you want to prevent that, you have to start banning versions
like 086 and 1.00 too.

-- 
Ciaran McCreesh