Re: [pacman-dev] Misleading info when epoch is used

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