Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 166522 - portage should only accept one version suffix
Summary: portage should only accept one version suffix
Status: RESOLVED INVALID
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core - Ebuild Support (show other bugs)
Hardware: All All
: High normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
: 171715 (view as bug list)
Depends on: 171259
Blocks: 166767 174542 174543
  Show dependency tree
 
Reported: 2007-02-12 16:35 UTC by SpanKY
Modified: 2007-06-22 16:55 UTC (History)
17 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description SpanKY gentoo-dev 2007-02-12 16:35:35 UTC
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
Comment 1 UncleOwen 2007-02-13 15:47:06 UTC
No. media-sound/alsa-driver-1.0.14_rc2_p3234 is a perfectly valid example, of why more than one suffix is needed.
Comment 2 SpanKY gentoo-dev 2007-02-13 17:23:17 UTC
alsa-driver is the first package ever to use more than one version suffix
Comment 3 Marius Mauch (RETIRED) gentoo-dev 2007-02-13 21:24:57 UTC
(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?
Comment 4 Jurek Bartuszek (RETIRED) gentoo-dev 2007-02-14 20:08:06 UTC
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.
Comment 5 Ciaran McCreesh 2007-02-14 20:32:50 UTC
_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.
Comment 6 Jakub Moc (RETIRED) gentoo-dev 2007-03-17 10:13:00 UTC
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 :)
Comment 7 Carsten Lohrke (RETIRED) gentoo-dev 2007-03-17 14:30:58 UTC
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.
Comment 8 Christel Dahlskjaer (RETIRED) gentoo-dev 2007-03-17 15:43:10 UTC
_alpha invalidly == _alpha0_p1
Comment 9 Georgi Georgiev 2007-03-17 16:00:59 UTC
(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.
Comment 10 Jakub Moc (RETIRED) gentoo-dev 2007-03-18 13:31:10 UTC
(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.
Comment 11 Jakub Moc (RETIRED) gentoo-dev 2007-03-21 19:27:52 UTC
*** Bug 171715 has been marked as a duplicate of this bug. ***
Comment 12 Jakub Moc (RETIRED) gentoo-dev 2007-03-22 07:31:29 UTC
*** Bug 171715 has been marked as a duplicate of this bug. ***
Comment 13 Stephen Bennett (RETIRED) gentoo-dev 2007-03-22 17:08:13 UTC
*** Bug 171818 has been marked as a duplicate of this bug. ***
Comment 14 Luca Barbato gentoo-dev 2007-03-25 22:20:22 UTC
I'd need it for mplayer... otherwise I'll make up my versions in another way =P
Comment 15 Marius Mauch (RETIRED) gentoo-dev 2007-03-25 23:05:55 UTC
See comment #3.
Comment 16 Ciaran McCreesh 2007-03-25 23:13:29 UTC
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...
Comment 17 SpanKY gentoo-dev 2007-03-26 00:10:53 UTC
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
Comment 18 Piotr Jaroszyński (RETIRED) gentoo-dev 2007-03-26 19:48:46 UTC
Shouldn't we first fix the docs and versionator.eclass and only then change packages in the tree?

QA: what do you think?
Comment 19 Dan 2007-04-02 22:39:24 UTC
(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
 
Comment 20 Dan 2007-04-02 22:43:52 UTC
Oops.. 
> foo-1_rc*_alpha* < foo-1_beta*
is obviously wrong.. it should be
foo-1_rc*_alpha* < foo-1
Comment 21 Gustavo Zacarias (RETIRED) gentoo-dev 2007-04-03 15:53:39 UTC
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.
Comment 22 TGL 2007-04-03 19:58:10 UTC
(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.
Comment 23 Stephen Bennett (RETIRED) gentoo-dev 2007-04-11 22:10:44 UTC
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?
Comment 24 Marius Mauch (RETIRED) gentoo-dev 2007-04-13 22:20:25 UTC
(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).
Comment 25 Ciaran McCreesh 2007-04-13 22:34:19 UTC
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.
Comment 26 Brian Harring (RETIRED) gentoo-dev 2007-04-13 22:46:42 UTC
(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.
Comment 27 Ciaran McCreesh 2007-04-13 22:59:31 UTC
(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.
Comment 28 Brian Harring (RETIRED) gentoo-dev 2007-04-13 23:11:14 UTC
(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.
Comment 29 Ciaran McCreesh 2007-04-13 23:15:54 UTC
(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...
Comment 30 solar (RETIRED) gentoo-dev 2007-04-13 23:45:11 UTC
(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.

Comment 31 Ciaran McCreesh 2007-04-13 23:52:01 UTC
(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.
Comment 32 SpanKY gentoo-dev 2007-04-14 01:57:10 UTC
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
Comment 33 SpanKY gentoo-dev 2007-04-14 02:08:56 UTC
manual pages have been updated ... maintainers of other documentation can update their own stuff
Comment 34 Georgi Georgiev 2007-04-14 02:36:35 UTC
(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.
Comment 35 Brian Harring (RETIRED) gentoo-dev 2007-04-14 05:57:26 UTC
(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*.
Comment 36 SpanKY gentoo-dev 2007-04-14 11:21:46 UTC
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
Comment 37 Ciaran McCreesh 2007-04-14 16:00:54 UTC
Alright. Could someone please provide a formal definition of how ordering is handled here then?
Comment 38 Marius Mauch (RETIRED) gentoo-dev 2007-04-14 16:28:53 UTC
(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.
Comment 39 Ciaran McCreesh 2007-04-14 16:48:00 UTC
(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
Comment 40 Georgi Georgiev 2007-04-14 17:00:29 UTC
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.
Comment 41 Ciaran McCreesh 2007-04-14 17:22:05 UTC
(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?
Comment 42 Alec Warner (RETIRED) archtester gentoo-dev Security 2007-04-14 20:07:11 UTC
(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
Comment 43 Ciaran McCreesh 2007-04-14 20:22:12 UTC
(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.
Comment 44 Dan 2007-04-16 23:07:55 UTC
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."
Comment 45 Christian Faulhammer (RETIRED) gentoo-dev 2007-04-23 12:13:59 UTC
*** Bug 175688 has been marked as a duplicate of this bug. ***
Comment 46 Marijn Schouten (RETIRED) gentoo-dev 2007-04-23 12:35:03 UTC
(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?

Comment 47 Marius Mauch (RETIRED) gentoo-dev 2007-04-23 15:24:10 UTC
(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.
Comment 48 Jurek Bartuszek (RETIRED) gentoo-dev 2007-06-22 16:10:52 UTC
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?
Comment 49 Marijn Schouten (RETIRED) gentoo-dev 2007-06-22 16:20:33 UTC
(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

Comment 50 Jurek Bartuszek (RETIRED) gentoo-dev 2007-06-22 16:55:40 UTC
That's even better. And yeah, it was eventually mentioned in the summary sent to dev@g.o@11.06, so my bad, sorry.