On Sun, Mar 30, 2008 at 05:40:44AM +0100, Ciaran McCreesh wrote: > On Sat, 29 Mar 2008 21:16:51 -0700 > Brian Harring <[EMAIL PROTECTED]> 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.
This isn't relevant to the discussion at hand; besides, 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.
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.
> > 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.
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.
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. 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.
> > > 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.
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).
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.
> 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
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.
There are other examples that come up from this, but you pointed out
one of the simpler ones above that actually argue *for* the change I'm
requesting.
> -- 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.
~harring
pgp1BHXjeWipO.pgp
Description: PGP signature
