FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux Pacman Development

 
 
LinkBack Thread Tools
 
Old 07-16-2008, 08:17 PM
Nagy Gabor
 
Default vercmp discussion (was: String freeze for 3.2 release)

> nicer, but harder ;-)
> See 84283672853350a84d2a71b72dc06e180cad1587, search for 'type
> mismatch'.
>
Hm. Wrong. With the new vercmp: 1.1 > 1.b (but in ASCII 'b' > '1'),
strange. Our problem is at the end of string: '' vs. alpha, as I see,
this case was handled after comment /* see if we ran out of segments on
one string */

Bye

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 07-17-2008, 03:23 PM
Nagy Gabor
 
Default vercmp discussion (was: String freeze for 3.2 release)

> It indeed looks like we just need to handle the case where it runs out
> of segments on one string.
> But we have to handle two cases : run out of segments with the
> -release number or without it.
> So in both cases, I handle it differently if the last remaining
> segment starts with a letter or not.
>
> I am not 100% sure that it will work correctly in every single cases,
> but the logic seems alright, there is no regression on all existing
> vercmp test, and the 4 new tests you posted in an older thread now
> pass fine.

I did a quick read on the new vercmp code. This is not an easy-to-read
code (and IMHO it is a bit overkill: strdup, free? - this is not
related to your patch), but it seems OK to me. Overall it is much better
than pre-patch state.

Some little observations:
1. This vercmp the code doesn't follow alpm code style (not related
to your patch, again):
while (*one == '0') one++;
if(!(*one && *two)) break;
I like this one-liners better than {} 3 liner version of these.
Is this allowed in our patches, too?
2. A very little notice:
Now 1.5b < 1.5, but 1.5.b > 1.5
In the "block terminology" of the code, 1.5b and 1.5.b are identical.
The difference appeared, because your patch uses isalpha() instead of
some "next block is alpha?" computation. To be honest, this may be
better than 1.5.b < 1.5, so you can skip this casuist note.

Bye

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 07-17-2008, 03:39 PM
Nagy Gabor
 
Default vercmp discussion (was: String freeze for 3.2 release)

> 2. A very little notice:
> Now 1.5b < 1.5, but 1.5.b > 1.5
> In the "block terminology" of the code, 1.5b and 1.5.b are identical.
> The difference appeared, because your patch uses isalpha() instead of
> some "next block is alpha?" computation. To be honest, this may be
> better than 1.5.b < 1.5, so you can skip this casuist note.
>
> Bye

This note inspired me to test '1.0. == 1.0'
You may think that this is useless, but image '1.0 ' versus
'1.0' (extra spacebar, '
' etc. character). The old code beats the new
one again :-P

Bye

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 07-17-2008, 03:41 PM
Nagy Gabor
 
Default vercmp discussion (was: String freeze for 3.2 release)

> This note inspired me to test '1.0. == 1.0'
> You may think that this is useless, but image '1.0 ' versus
> '1.0' (extra spacebar, '
' etc. character). The old code beats the
> new one again :-P

I mean 3.1 vercmp code beats 3.2 vercmp code. Xav, your patch is
excellent. (And I just joked here, of course.)

Bye

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 07-17-2008, 03:58 PM
Nagy Gabor
 
Default vercmp discussion (was: String freeze for 3.2 release)

> We need to take a step back here and examine things- RPM does a great
> amount of work to make version comparison work as good as possible.
>
> If we make a change to the core RPM code, we need to ask "why wasn't
> this change made upstream" or "why don't they do it this way". I guess
> that is how I see hardcoding things like "alpha" or "beta" into the
> detection code- they don't do it and seem to be fine with that.
>
> I feel for any changes proposed here, we need to explain why our
> version should deviate from the upstream code (as we do in the case of
> the pkgrel stuff) before I will really consider a patch to "fix"
> behavior.
>
> -Dan

OK. I believe that RPM guys are cool guys;-) I think they simply don't
need this mplayer 1.0rc2 versus 1.0 stuff, because they use different
versioning scheme (as I see):
http://dag.wieers.com/rpm/packages/mplayer/

I agree with you, that hacking vercmp is not a good idea, that's why I
say that we should revert the whole stuff. The old code was tested by
Archers for long time, and it seems to worked perfectly. (I know
that in case of reverting, our work on new vercmp was just a waste of
time, sry.) Personally I still don't see what is fixed by the new
"imported" code. Or it is notably faster? I can be convinced, but not
just saying "trust on RPM guys".

Bye

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 

Thread Tools




All times are GMT. The time now is 06:18 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org