[pacman-dev] vercmp behavior changed on "1.5b versus 1.5" compare
Hi! I hope this wasn't discussed here earlier, I haven't followed this thread lately. I think I said everything in subject, the old vercmp said that 1.5b<1.5, the new one says 1.5b>1.5. The same for 1.5b versus 1.5. Bye ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
The same for 1.5b versus 1.5.
typo: 1.5b-1 versus 1.5-1 Bye ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
2008/6/14 Nagy Gabor <ngaba@bibl.u-szeged.hu>:
The same for 1.5b versus 1.5.
typo: 1.5b-1 versus 1.5-1
Can you send a patch to vercmptest.sh and show us the difference before and after? Either way, I'm not convinced there is a right answer to what is greater and lesser, but it does warrent looking into as the behavior changed. I did see some comments in the new code alluding to some upstream changes that may have been related to version numbers similar to this. -Dan
On Sat, Jun 14, 2008 at 10:53:16AM -0500, Dan McGee <dpmcgee@gmail.com> wrote:
Either way, I'm not convinced there is a right answer to what is greater and lesser, but it does warrent looking into as the behavior changed. I did see some comments in the new code alluding to some upstream changes that may have been related to version numbers similar to this.
here is what upstream usually does: 1.0pre1 < 1.0rc1 < 1.0 < 1.0a if the package manager doesn't know anything about what 'a', 'pre' or 'rc' means, you can't handle all the situations. pacman (before the recent change, i haven't bisected it) handled pre/rc properly and package maintainers had to do hacks for 1.0a-like releases (samba, etc). if we want to improve this, then probably the way to go is something like what gentoo does: they have regex like (alpha|beta|rc|pre|p)(\d*)$ and handle the situation in such cases. of course if you add such a complexity then you can say 1.0a is greater than 1.0, and handle the prereleases manually.
Miklos Vajna wrote:
On Sat, Jun 14, 2008 at 10:53:16AM -0500, Dan McGee<dpmcgee@gmail.com> wrote:
Either way, I'm not convinced there is a right answer to what is greater and lesser, but it does warrent looking into as the behavior changed. I did see some comments in the new code alluding to some upstream changes that may have been related to version numbers similar to this.
here is what upstream usually does:
1.0pre1< 1.0rc1< 1.0< 1.0a
what about beta or b?
if the package manager doesn't know anything about what 'a', 'pre' or 'rc' means, you can't handle all the situations.
pacman (before the recent change, i haven't bisected it) handled pre/rc properly and package maintainers had to do hacks for 1.0a-like releases (samba, etc).
The recent changes are here : http://projects.archlinux.org/?p=pacman.git;a=commit;h=84283672853350a84d2a7... http://projects.archlinux.org/?p=pacman.git;a=commitdiff;h=54e1e3e642d834d8c... Currently, there is no special handling so it seems we just have an alphabetical order, that is : 1.0 < 1.0a < 1.0alpha < 1.0b < 1.0beta < 1.0p < 1.0pre < 1.0rc I am not sure how it was before though, maybe the only difference was that 1.0 was last instead of first?
On Sun, Jun 15, 2008 at 10:34:34AM +0200, Xavier <shiningxc@gmail.com> wrote:
here is what upstream usually does:
1.0pre1< 1.0rc1< 1.0< 1.0a
what about beta or b?
usually a project uses the alpha/beta _or_ the rc/pre schema, not both. but yes, this is just one more example about _if_ we want to make the current (read: before the recent changes) better, then the package manager needs to know about these releases.
Currently, there is no special handling so it seems we just have an alphabetical order, that is : 1.0 < 1.0a < 1.0alpha < 1.0b < 1.0beta < 1.0p < 1.0pre < 1.0rc
I am not sure how it was before though, maybe the only difference was that 1.0 was last instead of first?
it was how i described in my previous mail, so: 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.
2008/6/14 Nagy Gabor <ngaba@bibl.u-szeged.hu>:
The same for 1.5b versus 1.5.
typo: 1.5b-1 versus 1.5-1
Can you send a patch to vercmptest.sh and show us the difference before and after?
Either way, I'm not convinced there is a right answer to what is greater and lesser, but it does warrent looking into as the behavior changed. I did see some comments in the new code alluding to some upstream changes that may have been related to version numbers similar to this.
-Dan
_______________________________________________
Sorry, I cannot send a real patch atm (I can send it tomorrow, if it is needed), try adding these lines to vercmptest.sh (around line 90): runtest 1.5b-1 1.5-1 -1 runtest 1.5b 1.5 -1 runtest 1.5b-1 1.5 -1 runtest 1.5b 1.5.1 -1 Iirc, all "passed" with old version, none passes with new version. I think the old behavior is better. Bye ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
Nagy Gabor wrote:
Hi!
I hope this wasn't discussed here earlier, I haven't followed this thread lately. I think I said everything in subject, the old vercmp said that 1.5b<1.5, the new one says 1.5b>1.5. The same for 1.5b versus 1.5.
Just a small notice that this also became problematic today with the upgrade of nss, which was just upgraded from 3.12rc4 to 3.12. So it goes fine with pacman 3.1, but not with pacman git. And even when I try to upgrade nss with pacman -S nss, this fails because xulrunner has the following depends : nss>=3.12rc4
participants (4)
-
Dan McGee
-
Miklos Vajna
-
Nagy Gabor
-
Xavier