[pacman-dev] Misleading info when epoch is used

[Allan McRae]

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