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