[pacman-dev] Misleading info when epoch is used

Dan McGee dpmcgee at gmail.com
Wed Dec 8 00:40:55 CET 2010

On Tue, Dec 7, 2010 at 5:40 PM, Allan McRae <allan at 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.



More information about the pacman-dev mailing list