[aur-general] VCS PKGBUILD and Pacman 4.1: increase epoch?
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
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.
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).
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.
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?
On 5 April 2013 22:19, WorMzy Tykashi <wormzy.tykashi@gmail.com> wrote:
On 5 April 2013 20:17, Doug Newgard <scimmia22@outlook.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
On Fri, 5 Apr 2013 15:11:40 -0400, luolimao@gmail.com wrote: 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?
Oops. Forgot my reference. [0] https://wiki.archlinux.org/index.php/Arch_CVS_%26_SVN_PKGBUILD_guidelines
On Fri, 2013-04-05 at 22:20 +0100, WorMzy Tykashi wrote:
On 5 April 2013 22:19, WorMzy Tykashi <wormzy.tykashi@gmail.com> wrote:
On 5 April 2013 20:17, Doug Newgard <scimmia22@outlook.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
On Fri, 5 Apr 2013 15:11:40 -0400, luolimao@gmail.com wrote: 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?
Oops. Forgot my reference.
[0] https://wiki.archlinux.org/index.php/Arch_CVS_%26_SVN_PKGBUILD_guidelines
The versioning scheme is up to the maintainer, you're free to choose the one which makes more sense, and using the date is perfectly fine. The guidelines only provide examples. About epoch, I chose not to add one in my AUR packages. I believe it is an unnecessary complication, only makepkg is officially supported for AUR, epoch is irrelevant for such installs. Cheers. -- Maxime
On Fri, Apr 5, 2013 at 5:32 PM, Maxime Gauduin <alucryd@gmail.com> wrote:
On Fri, 2013-04-05 at 22:20 +0100, WorMzy Tykashi wrote:
On 5 April 2013 22:19, WorMzy Tykashi <wormzy.tykashi@gmail.com> wrote:
Oops. Forgot my reference.
[0] https://wiki.archlinux.org/index.php/Arch_CVS_%26_SVN_PKGBUILD_guidelines
The versioning scheme is up to the maintainer, you're free to choose the one which makes more sense, and using the date is perfectly fine. The guidelines only provide examples. About epoch, I chose not to add one in my AUR packages. I believe it is an unnecessary complication, only makepkg is officially supported for AUR, epoch is irrelevant for such installs.
Cheers. -- Maxime
I agree that epoch should not be included in AUR packages just to work around limitations in unsupported AUR helpers. If the AUR helpers cannot properly handle these, then the AUR helpers should be fixed rather than polluting the PKGBUILDs with workarounds. PKGBUILDs in the AUR are frequently sloppy enough as it is. Let's not make the problem any worse. Jason
On Fri, Apr 5, 2013 at 11:41 PM, Jason St. John <jstjohn@purdue.edu> wrote:
I agree that epoch should not be included in AUR packages just to work around limitations in unsupported AUR helpers. If the AUR helpers cannot properly handle these, then the AUR helpers should be fixed rather than polluting the PKGBUILDs with workarounds. PKGBUILDs in the AUR are frequently sloppy enough as it is. Let's not make the problem any worse.
Jason
The problem is that makepkg will update the pkgver of the downloaded PKGBUILD, so there is no reliable way of detecting an update without either bumping the epoch, or storing another copy of the downloaded PKGBUILD.
On Fri, 2013-04-05 at 23:49 +0200, Jan Alexander Steffens wrote:
On Fri, Apr 5, 2013 at 11:41 PM, Jason St. John <jstjohn@purdue.edu> wrote:
I agree that epoch should not be included in AUR packages just to work around limitations in unsupported AUR helpers. If the AUR helpers cannot properly handle these, then the AUR helpers should be fixed rather than polluting the PKGBUILDs with workarounds. PKGBUILDs in the AUR are frequently sloppy enough as it is. Let's not make the problem any worse.
Jason
The problem is that makepkg will update the pkgver of the downloaded PKGBUILD, so there is no reliable way of detecting an update without either bumping the epoch, or storing another copy of the downloaded PKGBUILD.
Indeed, but wasn't this already true even before pacman 4.1? -- Maxime
On Fri, Apr 5, 2013 at 5:57 PM, Maxime Gauduin <alucryd@gmail.com> wrote:
On Fri, 2013-04-05 at 23:49 +0200, Jan Alexander Steffens wrote:
On Fri, Apr 5, 2013 at 11:41 PM, Jason St. John <jstjohn@purdue.edu> wrote:
I agree that epoch should not be included in AUR packages just to work around limitations in unsupported AUR helpers. If the AUR helpers cannot properly handle these, then the AUR helpers should be fixed rather than polluting the PKGBUILDs with workarounds. PKGBUILDs in the AUR are frequently sloppy enough as it is. Let's not make the problem any worse.
Jason
The problem is that makepkg will update the pkgver of the downloaded PKGBUILD, so there is no reliable way of detecting an update without either bumping the epoch, or storing another copy of the downloaded PKGBUILD.
Indeed, but wasn't this already true even before pacman 4.1?
-- Maxime
Yes, previous versions of pacman had makepkg automatically update the pkgver of the PKGBUILD. Jason
On Fri, Apr 5, 2013 at 11:49 PM, Jan Alexander Steffens wrote:
The problem is that makepkg will update the pkgver of the downloaded PKGBUILD, so there is no reliable way of detecting an update without either bumping the epoch, or storing another copy of the downloaded PKGBUILD.
Updating the epoch each time seems a little too much. epoch does not seems to be designed for this. What I was speaking about is increasing the epoch when switching from one versioning scheme to another. I have taken the decision to do it. The reason is not about AUR helper. It is about consistency. Pacman is not aware from where your installed packages come from. It thus does not seem logical to generate new package version that are smaller than the old one and pretending they provide more recent version of the software. -- Cédric Girard
On 6 April 2013 18:21, Cédric Girard <girard.cedric@gmail.com> wrote:
On Fri, Apr 5, 2013 at 11:49 PM, Jan Alexander Steffens wrote:
The problem is that makepkg will update the pkgver of the downloaded PKGBUILD, so there is no reliable way of detecting an update without either bumping the epoch, or storing another copy of the downloaded PKGBUILD.
Updating the epoch each time seems a little too much. epoch does not seems to be designed for this.
What I was speaking about is increasing the epoch when switching from one versioning scheme to another. I have taken the decision to do it. The reason is not about AUR helper. It is about consistency. Pacman is not aware from where your installed packages come from. It thus does not seem logical to generate new package version that are smaller than the old one and pretending they provide more recent version of the software.
You are correct. Use epoch only where and when necessary -- do not abuse it. Its sole purpose is to ensure updated packages are treated as 'upgrades' even when their version according to, say, vercmp, is lower than the older package. Epoch should then be introduced, but it need not be bumped unless the versioning scheme changes once again. However, keep in mind that once epoch is introduced, it must always remain (even if at 1). -- GPG/PGP ID: C0711BF1
participants (8)
-
Cédric Girard
-
Doug Newgard
-
Jan Alexander Steffens
-
Jason St. John
-
Limao Luo
-
Maxime Gauduin
-
Rashif Ray Rahman
-
WorMzy Tykashi