On 08/12/10 22:31, Sven-Hendrik Haase wrote:
On 08.12.2010 00:40, Dan McGee wrote:
On Tue, Dec 7, 2010 at 5:40 PM, Allan McRae<allan@archlinux.org> wrote:
On 08/12/10 08:45, Sven-Hendrik Haase wrote:
On 07.12.2010 23:51, Nagy Gabor wrote:
$ sudo pacman -Su warning: supertuxkart: local (0.6.2a-2) is newer than community (0.7rc1-1)
What? First I thought that our vercmp code is buggy, but vercmp binary worked as expected. Then I figured out that my local package has epoch=1, but the epoch is unset on the community package (so this seems to be a packager bug).
So the above message is simply misleading (probably this is not the only one). It would be better to switch to a default version printing: "0.6.2a-2 [epoch=1]", or "1#0.6.2a-2" etc.
In fact I don't like neither force nor epoch. Epoch is just a version prefix, why don't we let the packager to workaround this (KISS)? We can introduce a new separator (now we have one: '.'), for example '#', and let the packager define his favourite pkgversion (maybe epoch in mind), like "1#0.6.2a-2". Epoch just complicates code and leads to "wtf" imho...
NG
I'm the packager of supertuxkart and I don't see what exactly went wrong. I'm not using any funny options in the PKGBUILD. I realize that I can fix your issue with options=(force) but is this an issue for everyone or just you due to something you did?
This is not your fault. We are working on a better system than options=('force') to a new system using "epoch" values. This is caused by Nagy installing a package he built using the epoch method and then attempting to update to a package without it. He doesn't even have to build it for it to do this- it is the automagic %FORCE% -> %EPOCH% translation we started to do. Old supertuxkart probably had a force (started being treated as epoch == 1), new one doesn't (epoch == 0), you lose.
-Dan
Sorry, I am still confused. Does this mean I should act on this by re-adding force or will you guys handle this in pacman somehow?
It only affects the maybe four or five of us running pacman-git. I think we can handle manually updating that package, so you are fine to do nothing for the time being. Allan