[pacman-dev] Misleading info when epoch is used
dpmcgee at gmail.com
Mon Dec 13 19:41:35 EST 2010
On Mon, Dec 13, 2010 at 6:41 PM, Nagy Gabor <ngaba at bibl.u-szeged.hu> wrote:
>> 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 "220.127.116.11a-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
> 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
More information about the pacman-dev