Dnia 19 września 2015 09:43:14 CEST, konsolebox <konsole...@gmail.com> napisał(a): >On Sat, Sep 19, 2015 at 5:05 AM, Michał Górny <mgo...@gentoo.org> >wrote: >> 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: >>> > 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 > >What issues? My spec was not meant to solve issues which can't be >solved by any universal algorithm. And it's not meant to add a >feature, but it can be used as a basis for one that would. > >Perhaps provide your own spec on how you could solve those issues then >let's see if your point is correct.
If you did the necessary research before sending your first mail, you'd know I did. If you can't use archives, I'll drop you a link when I get home. > >> It's silly because you >> still have a fair number of limitations which make parsing harder >> rather than easier. > >What limitations specifically? I'm not sure why you'd find it harder, >as compared to the current spec. And it's not even hard generally. Once again, I repeat: if your goal is to change the current spec a bit just to make one or two of your packages happier, then you're wasting time. The spec is to be judged generally, not compared to current state. > >> It's silly because you still have to remember >> the relation between 'alpha', 'beta', 'rc' and 'pre'. > >What kind of implementation would you have where you don't remember >those? Do you imply to completely avoid them? How would you get to >compare versions having alpha, beta, pre and rc then? Do you mean to >use another library to get each one's priority? Wouldn't that still >need to be specified in the spec? I've already told you. Explicit operator in rpm distinguishes post-version 'a' from pre-version alpha-'a'. > >> It's silly >> because those magical suffixes never match what upstreams use. >> And those are just a few sillinesses. > >Yeah unfortunately there could be just unlimited number of possible >suffixes and unlimited ways on how they could be used so the best >thing you could do is provide what's commonly used and just let the >ebuild maintainer decide how he could work around with those suffixes >so he could present it well on the ebuild. No. The solution is to provide a simple, universal scheme and let it express any version. > >>> 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. > >It's not a random idea as it only intends to simplify the current >spec, not drastically change it. And it doesn't really matter for me >to thoroughly understand them if you only intend to completely change >Gentoo's packaging system to be like them. It's not my spec's concern >to change things that way. So you want to introduce a lot of work to introduce a minor change. Plus confuse developers even more because they'll have to remember the tiny differences between versions in EAPI 5 and 6. > >> 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. > >I'm not sure what you mean, but you sure that adding the ability to >expression pre/post ordering does not make the algorithm even more >complicated? Note that you have to consider how you'd be able to >compare versions against other versions. No. Having 'less than' operator is simpler than long list of rules. But you clearly aren't interested in learning what we're discussing, so I don't see a point in discussing this any further. > >That also sounds to me like you just have to add a _post stage with a >+1 value and it would be enough, rather than having a complete >overhaul. Again, more limitations. Because someone knows exactly what's the best version scheme and everything else needs to be bent to match it. > >You say that you can express ordering explicitly: I find that it's >just the same problem you encounter when deciding what value to give >on _pre when encountering word versions like trial, devel, testing, >etc. > >I really think adding more commonly used suffixes should be enough. Longer lists of 'common'stuff definitely are the way to make spec simpler. > >Btw, can you give a link on how the pre/post ordering is expressed? I >can't find any RPM versioning spec that describes how it's done. Look for my spec of pkg-config. I'm pretty sure I've described the algorithm used for versions there. > >>> 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. > >Except that mine is unlikely to break compatibility with current >packages. You have issues against the very foundations of the current >implementation, but that's not really about my spec per se. You seem >to be barking at the wrong tree and I don't think that would help. It will. If you believe it doesn't, you don't understand how package managers work in Gentoo. If you change anything about version, most of silly assumptions break. Like you can't any longer depend on package using newer EAPI than yours. > >> 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. > >Unfortunately doing an overhaul may never happen unless you create >Gentoo 2.0 where a mirror of every package would work on it. So >simplifying it first (and optionally enhancing without breaking) could >be a good choice whether an overhaul happens later or not. -- Best regards, Michał Górny
