[pacman-dev] Misleading info when epoch is used

[Xavier Chantry]

On Tue, Dec 7, 2010 at 11:44 PM, Dan McGee <dpmcgee at gmail.com> wrote:
> On Tue, Dec 7, 2010 at 4:55 PM, Nagy Gabor <ngaba at bibl.u-szeged.hu> 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.