[aur-general] VCS PKGBUILD and Pacman 4.1: increase epoch?

Doug Newgard scimmia22 at outlook.com
Fri Apr 5 15:17:41 EDT 2013


On Fri, 5 Apr 2013 15:11:40 -0400, luolimao at 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 at 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. 		 	   		  


More information about the aur-general mailing list