Dnia 2015-09-19, o godz. 03:50:52 konsolebox <konsole...@gmail.com> napisał(a):
> On Sat, Sep 19, 2015 at 2:23 AM, Michał Górny <mgo...@gentoo.org> wrote: > > > > > > Dnia 18 września 2015 11:32:15 CEST, konsolebox <konsole...@gmail.com> > > napisał(a): > >>This is what an ideal and simple versioning spec should look like to > >>me. (Not the form, but the concept). I'm posting this here so it > >>could be used as an added reference to anyone that would consider > >>revising the current specification. > > > > The length of this mail itself proves that this is far from simple. > > Well that was called for yet still surprising. I'm not sure how the > length matters. And imagine how longer it would have been if I used > the 7 lexical algorithms of the current spec. If you call something simple, make it simple. if it can't be implemented simply, it's not simple. Simple as that. > > And similarly to the current solution it's full of silly special cases and > > magical rules. If you really want something simple and clean, take a look > > at the scheme used by pkg-config and rpm. > > Silly because it uses a not-so-monolithic approach which is more > convenient to implement and actually works? What special cases or > magical rules where you could find it more complex than the current > spec? It's silly because it shifts the existing terrible structure a bit and doesn't really solve most of its issues. It's silly because you still have a fair number of limitations which make parsing harder rather than easier. It's silly because you still have to remember the relation between 'alpha', 'beta', 'rc' and 'pre'. It's silly because those magical suffixes never match what upstreams use. And those are just a few sillinesses. > It's all about converting version strings to numerical values > and comparing them from left to right. And the idea on how things are > mapped is just a model and doesn't necessarily need to be followed > when making an implementation. If you don't want to allow "version > nodes" and only allow a single letter after the last version number of > the base part, then you could do it. How you convert 4a to a form you > could use for comparison is up to you - maybe just a struct with two > integral fields would suffice. But the idea of (1) using four > sections: base, stage, patch and revision, (2) converting each > sections to arrays or lists of integral numbers or finite-sized data > forms usable for comparisons, and (3) comparing them simply from left > to right, is there. I don't really understand what this paragraph was supposed to mean. Are you saying that your spec is fun because it's fun? > To add: comparing version strings in converted numerical forms is > friendly to the processor. You can also cache converted forms if you > want. On the other hand using a train of lexical algorithms that > parses and compares strings at the same time is painful to implement > and yields mixed-up code. Separating parsing from comparing is > convenient. > > And about pkg-config and rpm: I haven't thoroughly examined them yet, > but you sure their implementation is applicable to Gentoo? It might > just turn simpler because it's more limited or strict. Gentoo allows > stages, patches and revisions and uses predefined prefixes. Mine > starts on a flexible approach where "version nodes" are allowed > everywhere. Then you should have. It is appreciated when people do some *research* before throwing out random ideas on areas they have almost no idea of. And to save you some time reading: the rpm implementation is simpler and more flexible. It's free of stupidities like hardcoded suffix lists or forced component ordering. Ordering (pre/post) is expressed explicitly, and in many more cases you can avoid writing something completely different than what upstream uses. > If perhaps you mean to completely overhaul Gentoo's way of > implementing package versions, I don't think that would work. And is your change going to work? Because if you understood how ebuilds work, you'd know you practically can't change versioning because you'd immediately break compatibility between 'old' and 'new' ebuilds. This isn't something that was designed to support changes in version scheme, and changing that won't be anywhere close to easy. And if we ever agree on doing that, we should go for a complete and useful solution rather than some minor change with even smaller benefit. > Just to remind you I'm presenting the idea, not the draft nor the > implementation itself. So don't pay too much attention on how it's > made. I think I should have given it a more abstract form, but this > is just the first post. I also hope you can give more specific or > more elaborated criticizations about it, or perhaps give ideas on how > it should be better implemented. Also, you seem to have accidentally removed the mailing list from To/CC. -- Best regards, Michał Górny <http://dev.gentoo.org/~mgorny/>
pgp657fcCqcAA.pgp
Description: OpenPGP digital signature
