2008/6/20 Xavier <shiningxc@gmail.com>:
2008/6/20 Nagy Gabor <ngaba@bibl.u-szeged.hu>:
You may trust rpm guys, but don't forget that rpm based distros usually use different versioning scheme, so '1.0b versus 1.0' is not a real life example there: alsa-lib-1.0.14-0.4.rc3.fc7.i386.rpm (Fedora) mplayer-1.0-0.20.pre7.0.rh9.rf.i386.rpm (Fedora)
Yeah, I was also thinking about that. But what is strange is that in the rpm epoch link I just gave, they give an example that matches our situation.
Not to say that I think the new vercmp is "wrong" and the old one is "correct", but
2008/6/15 Miklos Vajna <vmiklos@frugalware.org>:
1.0rc < 1.0 -> good 1.0pre < 1.0 -> good 1.0alpha < 1.0 -> good 1.0beta < 1.0 -> good 1.0a < 1.0 -> bad 1.0b < 1.0 -> bad 1.0b (if 'a' stands for alpha) < 1.0 -> good 1.0b (if 'b' stands for beta) < 1.0 -> good
so it was 6 good vs 2 bad while now it's 6 bad vs 2 good, if i haven't miscounted something.
the old vercmp also maintains backwards compatibility, i.e. packages that used to have options=('force') (e.g. samba) will still have it, and packages that used to not have options=('force') when using *{rc,beta,pre} won't need it. (I didn't counted anything though :-P).
I mostly dislike the change just because it will require removing/adding options=('force') to packages without a real need (IMO). /me shrugs
Yes. And in Xavier's link there is a "Problems with Dependencies" paragraph. So it is required to minimize force/epoch in order to calculate 'foo>=1.3-1' dependencies correctly. Question: any foo package with force will satisfy this. Right? Bye