Bugzilla Bug 166522

portage considers these valid atoms:
media-sound/alsa-driver-1.0.14_rc2_p3234
media-sound/alsa-driver-1.0.14_rc2_p3234_alpha_beta_pre_rc_p

i think only one suffix should be allowed out of the list:
alpha beta pre rc p

No. media-sound/alsa-driver-1.0.14_rc2_p3234 is a perfectly valid example, of
why more than one suffix is needed.

alsa-driver is the first package ever to use more than one version suffix

(In reply to comment #2)
> alsa-driver is the first package ever to use more than one version suffix

Because in <2.1 it wasn't possible and in previous 2.1 versions repoman
prevented them from being committed (for compat reasons). Originally this
feature was requested by the kernel team.
Any particular reason why you don't want multiple suffixes to be valid?

IMO multiple suffixes are needed. Suppose you have a CVS snapshot of a
development version of some package. You know there is going to be a rc3 in the
future. Therefore you name your ebuild like that:

package-name-1.0_rc3_preYYYYMMDD.ebuild

because subsequent official rc versions come out rather rarely you want to
fetch a fresh snapshot from the repository and put it in portage.

Now package-name developer decides to release package-name-1.0_rc3. You want
that one in portage, so you create a new ebuild named:

package-name-1.0_rc3.ebuild

However, if you want users to upgrade to newer snapshots you should name your
next ebuilds like that:

package-name-1.0_rc4_preYYYYMMDD.ebuild or
package-name-1.0_rc3_pYYYYMMDD.ebuild

If you see any way of doing this without using multiple suffixes, let me know.

_alpha_p is probably sane, since _p isn't like _alpha and the like
ordering-wise. _alpha_beta and _alpha_pre are silly.

Either way, stuff in the tree (e.g. versionator) doesn't support this... The
format needs to be formally agreed upon and implemented globally.

Hmm, so how about something like this?

- you can have each of alpha/beta/pre/rc/p appear just *once* in every atom
- alpha/beta/pre/rc + p is valid, all the rest is invalid

(While I'd say that alpha/beta + pre/rc/p still makes sense, while alpha_beta
plain doesn't, it'd be inconsistent and more complicated). At any rate,
multiple suffixes are IMO needed, just the combos should be sane :)

The additional suffix has been explicitly requested for local ebuild
modifications, so I think we shouldn't mess with it for the same reason as we
don't install anything in /usr/local. Users claim, not ours.

When there're really widespread problems expressing version order, it may
indeed be the sign that there's something wrong with our versioning scheme.
ALSA is really a special case, as linux.org and alsa-project.org absolutely
suck regarding their non-coordinated release cycle.

_alpha invalidly == _alpha0_p1

(In reply to comment #4)
> package-name-1.0_rc4_preYYYYMMDD.ebuild or
> package-name-1.0_rc3_pYYYYMMDD.ebuild

What about PN-1.0_rc3.14 -- no need to think about valid/invalid suffix
combinations and their meaning; doesn't contradict ebuild(5) as much as
alsa-driver currently does.

(In reply to comment #9)
> What about PN-1.0_rc3.14

Nope, that's a different feature, and not meant for use in official
repositories at all. See RFC: Portage local package revisions thread on
gentoo-dev mailing list.

*** Bug 171715 has been marked as a duplicate of this bug. ***

*** Bug 171715 has been marked as a duplicate of this bug. ***

*** Bug 171818 has been marked as a duplicate of this bug. ***

I'd need it for mplayer... otherwise I'll make up my versions in another way =P

See comment #3.

So if multiple suffixes are allowed, you need to:

* Update the devmanual and man pages
* Update versionator.eclass
* Provide a proper definition of exactly how comparisons are to work

This seems like a rather horrible solution to use just to keep a couple of
packages happy...

not closed until documentation is fixed ...

also, if you want to allow certain combinations, that's one thing, but it seems
pointless to allow infinite strings as pointed out in original comment

Shouldn't we first fix the docs and versionator.eclass and only then change
packages in the tree?

QA: what do you think?

(In reply to comment #16)
> So if multiple suffixes are allowed, you need to:
[snip]
> * Provide a proper definition of exactly how comparisons are to work
> 
> This seems like a rather horrible solution to use just to keep a couple of
> packages happy...
> 

To propose a "how comparisons are to work:" (without looking at how portage
handles it..)

It seems like the logical way for handle it would be to match it left to right
with each additional version suffix only being compared if the previous suffix
is equal.

Examples:
foo-1_rc*_alpha* < foo-1_beta*
foo-1_rc1_alpha1 < foo-1_rc2
foo-1_rc1_alpha1 < foo-1_rc1_alpha2

Oops.. 
> foo-1_rc*_alpha* < foo-1_beta*
is obviously wrong.. it should be
foo-1_rc*_alpha* < foo-1

I agree with Spanky, this should be documented.
Also some combinations shouldn't be allowed at all, like alpha+beta, alpha+rc,
beta+rc since they're pointless and just beg for future issues like this one
over and over again.

(In reply to comment #21)
> Also some combinations shouldn't be allowed at all, like alpha+beta, alpha+rc,
> beta+rc since they're pointless and just beg for future issues like this one
> over and over again.
> 

For what it's worth, I disagree. 
I think that allowing only some particular combinations complicates both:
 - specification: it's easier to define a general semantics recursively than to
give a list of special cases,
 - implementations: think about writing a regexp which matches valid versions
for instance.

Also, i don't really see the benefit of forbidding stupid version strings. 
Sure, supporting "0.0.0.0.0.0.0.0.1234567" is pointless (no sane upstream would
use that), but fact is it is supported and has never proved to be an issue.

Personally I'd be inclined to go with zero or one of _alpha _beta _pre _rc
followed by zero or one of _p. Anyone have a problem with this?

(In reply to comment #23)
> Personally I'd be inclined to go with zero or one of _alpha _beta _pre _rc
> followed by zero or one of _p. Anyone have a problem with this?

I still don't see a compelling reason to add such arbitrary restrictions. I may
be convinced to limit the number of suffixes, but to restrict the possible
combinations you'll need a really good reason ("doesn't make sense to me" isn't
good enough).

It's a question of providing only what makes sense. Portage's version
specification isn't designed to handle absolutely every scheme that upstream
could possibly dream up, only those that are widely enough used that it's worth
doing so.

(In reply to comment #25)
> It's a question of providing only what makes sense. Portage's version
> specification isn't designed to handle absolutely every scheme that upstream
> could possibly dream up, only those that are widely enough used that it's worth
> doing so.
You're not really providing a good argument there for why the generic suffix
mechanism should be castrated down to whatever limited subset you want.

Besides, limiting the suffixes used in gentoo-x86 is really a devmanual issue,
meaning limit it in repoman, rather then gutting it in the manager.

(In reply to comment #26)
> You're not really providing a good argument there for why the generic suffix
> mechanism should be castrated down to whatever limited subset you want.

Because _alpha_beta doesn't make sense.

(In reply to comment #27)
> (In reply to comment #26)
> > You're not really providing a good argument there for why the generic suffix
> > mechanism should be castrated down to whatever limited subset you want.
> 
> Because _alpha_beta doesn't make sense.

Then don't support it in paludis.  Point is, it's a general mechanism- if you
want to limit the possible combinations, do it in repoman/devmanual.

*You* may not _alpha_beta makes sense, but there have been weirder upstream
versions then that.  It's zero cost to support it, you're not providing any
reason but "It's stupid" to drop it.

Dislike the combinations, limit them via tree rules; trying to force it out of
the implementation seems a wee bit stupid to me however.

(In reply to comment #28)
> (In reply to comment #27)
> > Because _alpha_beta doesn't make sense.
> 
> Then don't support it in paludis.  Point is, it's a general mechanism- if you
> want to limit the possible combinations, do it in repoman/devmanual.

The outcome of this bug is being used to decide PMS too...

(In reply to comment #29)

> The outcome of this bug is being used to decide PMS too...

Can you add this bug as a blocker of that bug # please till something 
official is decided.

(In reply to comment #30)
> (In reply to comment #29)
> > The outcome of this bug is being used to decide PMS too...
> 
> Can you add this bug as a blocker of that bug # please till something 
> official is decided.

There's no particular PMS bug. Anything open with pms-bugs on the Assigned: or
Cc: list is considered to be blocking PMS.

i'd say any combination of these prefixes generally doesnt make sense, but that
doesnt really matter anymore seeing as how upstream people have done this sort
of stuff

manual pages have been updated ... maintainers of other documentation can
update their own stuff

(In reply to comment #32)
> i'd say any combination of these prefixes generally doesnt make sense, but that
> doesnt really matter anymore seeing as how upstream people have done this sort
> of stuff

When has any upstream ever done this sort of stuff?

If I recall correctly, it was only alsa-driver and currently is mplayer who
have ever made use of this "feature". Both of those were/are not supported
upstream versions. More like a gentoo issue with pushing out a premature
pre-release. And I am pretty sure that there are other ways to work around this
nonsense.

If a patch in a non-finished release is that important -- add the patch to the
preceding version and push it as a -r bump. I know that revbumps are not
intended for that, but an unofficial svn/cvs/whatever snapshot should never go
stable anyway.

(In reply to comment #34)
> (In reply to comment #32)
> > i'd say any combination of these prefixes generally doesnt make sense, but that
> > doesnt really matter anymore seeing as how upstream people have done this sort
> > of stuff
> 
> When has any upstream ever done this sort of stuff?
mplayer upstream has used variant of multiple suffixes.

> If I recall correctly, it was only alsa-driver and currently is mplayer who
> have ever made use of this "feature". Both of those were/are not supported
> upstream versions.

Again, look upstream, specifically at the collection of trys, alpha additions
to the suffixes, etc.

You provided the example- pull the SRC_URI from the tree, go looking for likely
candidates- know you'll find more.

> And I am pretty sure that there are other ways to work around this
> nonsense.

Injecting fake versions, breaking from upstreams version, etc.  It's been done,
and it sucks.

> If a patch in a non-finished release is that important -- add the patch to the
> preceding version and push it as a -r bump. I know that revbumps are not
> intended for that, but an unofficial svn/cvs/whatever snapshot should never go
> stable anyway.

You *can* jam it in wherever, that doesn't mean it's *wise* to do so.  What
you're basically suggesting is having a -rX that is from a different release,
instead of misc fixes, which is what -rX is supposed to be *about*.

i wouldnt refer to the multimedia usage as "pushing out premature upstream
stuff" as that is often expected/normal behavior in that realm of open source
... look at ffmpeg for example; they completely expect distributions to make
their own snapshots

as Brian said, our policy specifically says that -r# is for Gentoo revisions
only, not for additionally tracking upstream ... that leaves peeps in the
middle without any sane way of version tracking

Alright. Could someone please provide a formal definition of how ordering is
handled here then?

(In reply to comment #37)
> Alright. Could someone please provide a formal definition of how ordering is
> handled here then?

Third paragraph in PMS section 2.3 explains it pretty good, just have to
mention that it's iterative.

(In reply to comment #38)
> (In reply to comment #37)
> > Alright. Could someone please provide a formal definition of how ordering is
> > handled here then?
> 
> Third paragraph in PMS section 2.3 explains it pretty good, just have to
> mention that it's iterative.

It's the iterative part that's the problem. Specifically, I need a decent
description that explains the following ordering (assuming comment #19 is
accurate):

  1_alpha1_alpha1
  1_alpha1_beta1
  1_alpha1
  1_alpha1-r1
  1_alpha1_p1

OK, so just to summarize, the problem that needs to be solved is:

  Support unofficial upstream releases and match the upstream version
  as closely as possible

(No negative meaning in "unofficial" above, considering the ffmpeg comment.)

I'm sorry for getting back to my suggestion in comment #9, but why is that
unfeasible again? To refresh your memory, the proposal is to support
non-integer _suffix as in:

  category/program_suffixNUMBER.ANOTHERNUMBER

It pretty clearly gives the intention of the version -- foo_alpha3.14 is
clearly newer than foo_alpha3 and older than foo_alpha4. Jakub (in comment #10)
shot it down with a referral to a thread that was all about incremental -r
revisions like -rX.Y.Z -- not at all related to my proposal. Considering that
_alpha_beta, _beta_rc and anything but an incremental release over the _suffix
version are quite ridiculous and/or overly complicated (*you* try comparing
_beta1_p99 and _beta2_pre1), why not simply settle for non-integer numbered
_suffixes?

The upside of non-integer _suffixes:
- solves the current problem: support for releases between _rc10 and _rc11
- no (major) contradiction with any of the current documentation
- non-ambiguous -- both "less than" (_alpha, _pre, _beta) and "greater than"
(_p) suffixes are not mixed for extra confusion
- if any further explanation about the intended meaning of the version is ever
necessary, it can be done in much less words than any of the other proposals in
this bug
- it's naturally compatible with real weird upstream releases:
Mplayer-1.0pre7try2 naturally maps to mplayer-1.0_pre7.2, and a subsequent
snapshot release can become mplayer-1.0_pre7.2.`date +%Y%m%d` (I'm not really
suggesting support for Z as in _suffixX.Y.Z but it seems trivial)
- developers seeing multiple suffixes will not be tempted to use an invalid
suffix combination (possible in other proposals where only certain combinations
are allowed)

As nobody else even considered the above, I am pretty sure that should be a
good reason. I hope the opponents of the idea would at least share that reason.

(In reply to comment #40)
> OK, so just to summarize, the problem that needs to be solved is:
> 
>   Support unofficial upstream releases and match the upstream version
>   as closely as possible

No it isn't.

The problem that needs to be solved is:

What subset of Portage's currently supported atom syntax should be considered
usable? What are the precise ordering rules for the new syntax? What
documentation needs updating as a result?

(In reply to comment #39)
> (In reply to comment #38)
> > (In reply to comment #37)
> > > Alright. Could someone please provide a formal definition of how ordering is
> > > handled here then?
> > 
> > Third paragraph in PMS section 2.3 explains it pretty good, just have to
> > mention that it's iterative.
> 
> It's the iterative part that's the problem. Specifically, I need a decent
> description that explains the following ordering (assuming comment #19 is
> accurate):
> 
>   1_alpha1_alpha1
>   1_alpha1_beta1
>   1_alpha1
>   1_alpha1-r1
>   1_alpha1_p1
> 

Left to right ordering so we compare each version.

All versions start with 1, so so far they are all 'not unequal'.
All versions follow with alpha1, so far they are all still 'not unequal'.
Then we can just compare the final elements so:

alpha1
beta1
(implicitly r0)
r1
p1

I assume you know how to compare those already, since they are a common case.
My thought is then, where are you confused as to how the rules are applied?

As far as documentation, the portage docs were updated by Mike; I think
devmanual needs to be patched though, and probably someone needs to remove the
devrel docs on it.

-Alec

(In reply to comment #42)
> I assume you know how to compare those already, since they are a common case.
> My thought is then, where are you confused as to how the rules are applied?

I'm not confused as to how they're applied. I'm looking for a technically sound
description that's suitable for someone who doesn't.

How about something like:

"Versions sections are separated by an underscore.

Versions are compared by section from left to right following normal rules. 
Subsequent sections only need to be compared if the previous section is equal."

*** Bug 175688 has been marked as a duplicate of this bug. ***

(In reply to comment #44)
> How about something like:
> 
> "Versions sections are separated by an underscore.
> 
> Versions are compared by section from left to right following normal rules. 
> Subsequent sections only need to be compared if the previous section is equal."

or:

"Versions are ordered by lexicographic ordering of '_'-separated version atoms.
See http://en.wikipedia.org/wiki/Lexicographic_order for more info."

Also, would "1.2.3_4.5.6" or "pre3" be valid versions? or is the first version
atom special?

(In reply to comment #46)
> Also, would "1.2.3_4.5.6" or "pre3" be valid versions? or is the first version
> atom special?

Both are invalid.

Basically - what's the status of this debate? AFAIR The Council have decided
that multiple version suffxes are illegal (April 2007). Do we still need this
bug to be open?

(In reply to comment #48)
> Basically - what's the status of this debate? AFAIR The Council have decided
> that multiple version suffxes are illegal (April 2007).

Actually they have decided that they are legal, see
[http://www.gentoo.org/proj/en/council/meeting-logs/20070510.txt]:

[16:39] <wolf31o2> vote: should we allow multiple suffixes?
[16:39] <vapier> which is true ... if you support one combination of suffixes,
you might as well make it completely arbitrary
[16:40] <wolf31o2> I tend to agree that there's no reason to restrict it... the
minute we do, somebody will make a version that does something we didn't expect
and we're back to where we are now
[16:40] <wolf31o2> and I vote yes, we should allow multiple suffixes
[16:40] <vapier> right, i'm for it
[16:40] * Uber votes yes also
[16:40] <fmccor> I'll vote Kugelfang yes.
[16:40] <KingTaco> if we're going to do multiple suffixes then we need to
document the order
[16:40] <wolf31o2> sure
[16:40] <vapier> the order is documented
[16:40] <fmccor> Yes.
[16:40] <kloeri> the thing about restricting it isn't technical but users
should be able to look at 5 ebuilds and see what's newest which can get rather
complex with multiple suffixes imo
[16:41] <vapier> i dont understand that argument at all
[16:41] <KingTaco> I vote no
[16:41] <wolf31o2> kloeri: robbat2|na: ?
[16:41] <vapier> if a > b > c, then why do you need to document a > a.b > a.c >
b
[16:41] <kloeri> I think some cases might make sense but I don't think we
should allow arbitrary combinations
[16:41] <wolf31o2> well, I guess it goes in anyway... so now... should we limit
what suffix combinations are allowed?
[16:41] <wolf31o2> heh
[16:42] <kloeri> imo we should
[16:43] <vapier> i'm with genone on this ... since there is no technical
limitation, imposing our own arbitrary rules on an arbitrary system seems
pointless to me
[16:43] <Uber> i'm with vapier, we shouldn't restrict needlessly
[16:43] <wolf31o2> I agree with you/genone... I see no reason to limit it when
it isn't a technical limitation we have to worry about
[16:44] <wolf31o2> KingTaco: fmccor: robbat2|na: ?
[16:44] <KingTaco> wolf31o2, I already voted no to multiple suffixes
[16:44] <wolf31o2> ok...
[16:45] <fmccor> Conditional agree.  As someone mentioned, they need to be
human-decipherable without too much effort.
[16:45] <fmccor> (Agree with vapier Uber etc)
[16:45] <wolf31o2> ok.. that makes a majority

That's even better. And yeah, it was eventually mentioned in the summary sent
to dev@g.o@11.06, so my bad, sorry.