Dnia 2015-09-20, o godz. 16:40:16 konsolebox <konsole...@gmail.com> napisał(a):
> On Sat, Sep 19, 2015 at 10:54 PM, Michał Górny <mgo...@gentoo.org> wrote: > > Here's my old proposal: https://bugs.gentoo.org/show_bug.cgi?id=526456 > > > > Dnia 19 września 2015 14:59:35 CEST, konsolebox <konsole...@gmail.com> > > napisał(a): > >>On Sat, Sep 19, 2015 at 6:55 PM, Michał Górny <mgo...@gentoo.org> > >>wrote: > >>> Dnia 19 września 2015 12:27:32 CEST, konsolebox > >><konsole...@gmail.com> napisał(a): > >>>>On Sat, Sep 19, 2015 at 4:01 PM, Michał Górny <mgo...@gentoo.org> > >>>>wrote: > >>> Which one is simpler: > >>> > >>> 1. _pre, _alpha, _beta, _rc... is earlier than no suffix, _p is newer > >>than no suffix, > >>> > >>> 2. ~ is earlier than no suffix? > >>> > >> > >>Ok I have to admit that no. 2 is simpler. It's less descriptive and > >>requires general or specific guidelines on representing common > >>suffixes, but it allows more flexibility. I actually had the idea > >>earlier of using _pre but using a symbol is more appropriate. Besides > >>_pre already has a position which is > _beta and < _rc. > >> > >>So what would pkg-1.4_alpha1_p20 look like if you convert it to a form > >>that uses ~? > > > > You shouldn't start with old gentoo version but with whatever upstream > > uses. The goal is that the scheme is really upstream friendly. > > > > So Python-3.5.0a2 would be 3.5.0~a2. We just add the tilde to indicate it's > > alpha-a and not post-version a. > > > Then, instead of full alpha/beta substitution we just strip the tilde. > > Strip the tilde? SRC_URI=".../Python-${PV/~/}.tar.xz" > > > So in your case, it could be 1.4~alpha1_p20, or 1.4~a1_20, or… > > Or just like my idea of using multiple nodes which is 1.4~a1.20? > Although I don't agree about concatenating the patch (_p) or another > custom suffix's value against the preceding suffix - because the > preceding suffix could actually have a dotted value in _alpha in which > case comparing the minor numbers would be ambiguous. > > >>Also what about if the package has a custom "newer than no suffix" > >>suffix used like pkg-1.4-sr5-p20? > > > > Well, sr would be used as letter version component but it shouldn't hurt. > > So we add `sr` as a known suffix, what about other possible suffixes? No, we don't. There are *no* known magical suffixes. 'sr' is just text version part, like 'a', 'b', 'c', 'za'... > The point is, how would you compare custom suffixes when you don't > apply definite levels to them? Which one would come before or after > another? And comparing lexicographically does not always apply. Would > everyone have to convert them to presentable values where you could > calculate a number or compare in lexicographical order? You can't solve every single problem. Instead, you can apply simple and generic rules that could work in majority of cases, and be clearly changed in the remaining cases. > > > We could even extend this to allow multiple tildes and add another symbol > > that evaluates as higher than any version component. > > Yes, like adding _post? No, 'post' is string which again imposes limitation on upstream naming of versions. Use symbols as separators are symbols already. > This really sounds like it can be solved by allowing multiple version > nodes on _pre and _post just like what I said earlier. > > If you want you can have symbol versions of those but it would not be > necessary to actually remove the existing suffixes. You really can't think flexibly, can you? You always try to hardcode some strings, some arbitrary limitations because someone happened to implement Portage like this without too much thinking years ago. -- Best regards, Michał Górny <http://dev.gentoo.org/~mgorny/>
pgp4RCD4Z9_wr.pgp
Description: OpenPGP digital signature
