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