On Tue, Dec 7, 2010 at 5:40 PM, Allan McRae 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. http://repos.archlinux.org/wsvn/community?op=comp&compare[]=%2Fsupertuxkart%2Ftrunk@25176&compare[]=%2Fsupertuxkart%2Ftrunk@34147 -Dan

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 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.

http://repos.archlinux.org/wsvn/community?op=comp&compare[]=%2Fsupertuxkart%2Ftrunk@25176&compare[]=%2Fsupertuxkart%2Ftrunk@34147

-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

On Tue, Dec 7, 2010 at 11:44 PM, Dan McGee wrote:

On Tue, Dec 7, 2010 at 4:55 PM, Nagy Gabor wrote:

...

...

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...

Well, of course a new separator is not necessary, packager can do everything with '.', e.g. he can use "1.0.6.2a-2". It is just more readable to the user (and the packager). The key here is that epoch is no more than a simple version prefix, and I think it is needless to introduce %EPOCH% database field etc.

Because this is ugly as hell and it will result in 100+ bug reports and "why is the version number off" questions in the first year. KISS applies both ways- keep the code simple, but keep developers lives from becoming enveloped in the first level of hell, and this suggestion would unfortunately do that. :/

I am with Nagy until you convince me otherwise :) 'version number off' is exactly what happens in Nagy's example : warning: supertuxkart: local (0.6.2a-2) is newer than community (0.7rc1-1) The real version that pacman uses is epoch+version and thus the pkgver printed here is wrong and confusing. pkgver and epoch can be separate (in pkgbuild, db, etc..) but they need to be handled together. This includes being printed together. This raises then the question of implementation. It would definitely be simpler if there was just one field in pacman and in the db, and the result would be similar. This would also mean you could easily predict pacman behavior by just comparing pkgver using vercmp, which would be nice to have. Then we can wonder if we need a epoch field in the PKGBUILD or if packagers could just handle it manually by 'sanitizing' the pkgver, and adding an epoch version as a prefix is just one way to do that. But in any cases, Nagy's original report about misleading info is valid and I am sure it would trigger bug reports.

Pierre Schmitz wrote:

I don't know if this was already discussed or even implemented, but is the epoch value taken into account when resolving dependencies? I am asking because I couldn't update from openssl 1.0.0 to 1.0.0a using the force switch as this broke all deps like >1.0.0.

yeah thats why we want to move away from 'force' to the epoch concept. (But there are different ways to implement epoch :))

On Mon, Dec 13, 2010 at 6:41 PM, Nagy Gabor wrote:

...

On Tue, Dec 7, 2010 at 11:44 PM, Dan McGee wrote:

...

On Tue, Dec 7, 2010 at 4:55 PM, Nagy Gabor wrote:

...

...

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...

Well, of course a new separator is not necessary, packager can do everything with '.', e.g. he can use "1.0.6.2a-2". It is just more readable to the user (and the packager). The key here is that epoch is no more than a simple version prefix, and I think it is needless to introduce %EPOCH% database field etc.

Because this is ugly as hell and it will result in 100+ bug reports and "why is the version number off" questions in the first year. KISS applies both ways- keep the code simple, but keep developers lives from becoming enveloped in the first level of hell, and this suggestion would unfortunately do that. :/

I am with Nagy until you convince me otherwise :)

Well, I may convince you otherwise. :-)

Unfortunately, it seems that there are situations, when we cannot workaround epoch: ":: Starting full system upgrade... warning: python-fuse: local (20090921-1) is newer than community (0.2.1-2)"

What can we do without epoch? Not too much (maybe keep date-like versions). Until recently I've forgot about this, but probably these situations are more common than pacman-incompatible versioning schemes (which the packager could workaround easily).

Ahh, I see why you were not for this before. Now your view is much more in line with ours. But I disagree that the packager should have to work around these in all cases- it is much easier to search the internet for problems if someone is referring to the real version rather than our invented version.

With epoch, the epoch=0 default is important. Then, in fact, all package versions start with "0." Personally I don't want to see "0." versions everywhere. That is "ugly as hell", indeed.

Now I start to accept this epoch stuff... So I also think that this epoch concept is needed, but the implementation is need to be discussed. (I can still accept "1#0.2.1-2", too, but new separator is needed, and missing '#' must be interpreted as epoch=0.)

Of course. We actually had zero intention of ever showing epoch! You actually showed me otherwise that we might want a way to work it into a version string at times, for things like dependency resolution. And I don't plan on ever showing this to people in most output, regardless of being 0 or greater than 0. I think '#' is a good choice of separator here- the chance of that being in an existing version string is minimal (and not even possible?) as far as I know (`pacman -Sl | grep -F '#'` returns zero results). -Dan