[pacman-dev] vercmp discussion (was: String freeze for 3.2 release)

[Nagy Gabor]

> 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