On 5 April 2013 20:17, Doug Newgard <scimmia22@outlook.com> wrote:
On Fri, 5 Apr 2013 15:11:40 -0400, luolimao@gmail.com wrote:
On 04/05/2013 10:05 AM, Jan Alexander Steffens wrote:
On Fri, Apr 5, 2013 at 4:02 PM, Cédric Girard <girard.cedric@gmail.com wrote:
Hello,
I was wondering, as I am updating my PKGBUILDs to use the new VCS features of pacman, if this specific case need an epoch increase for those packages.
Packages version were generated from the date (eg 20130401) and thus will probably be bigger than new versions from the tags (eg 0.3.1.32.gfb4117d). Thus an epoch increase should be needed to have a correct behavior.
But it seems most packagers are not increasing the epoch as they are switching to this new versionning scheme.
Is there a recommendation on this?
-- Cédric Girard
Yes, the correct thing to do would be bumping epoch for every new release of the PKGBUILD. I think you mean it just needs to be bumped this once, since the tag versions are going to be increasing from here onward... (unless, of course, the pkgver() function is changed in a way that this is not true).
I'm sure an epoch is the correct way to handle this, but we have to remember this is the AUR, not the official repos. The officially supported way of building from the AUR is using makepkg then install with pacman, in which case the epoch won't make a difference. It will stop pacman from giving you a warning, and in return you're stuck with an epoch for the life of the package. If the maintainer wants to make it easier for AUR helpers, go ahead and add the epoch, but I don't see it as required in this case.
Is the new way of pkgver-ing VCS packages mandatory? The VCS Guidelines[0] isn't clear, it just says that pkgver is more controllable, and lists a few examples. Would it be wrong for me to continue using the date +%Y%m%d versioning system, or is up to individual maintainers to choose which system is more appropriate?