Re: [aur-general] VCS PKGBUILD and Pacman 4.1: increase epoch?
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
Re: [aur-general] VCS PKGBUILD and Pacman 4.1: increase epoch?
On 6 April 2013 18:21, Cédric Girard girard.ced...@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
[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
Re: [aur-general] VCS PKGBUILD and Pacman 4.1: increase epoch?
On Fri, Apr 5, 2013 at 4:02 PM, Cédric Girard girard.ced...@gmail.comwrote: 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.
Re: [aur-general] VCS PKGBUILD and Pacman 4.1: increase epoch?
On 04/05/2013 10:05 AM, Jan Alexander Steffens wrote: On Fri, Apr 5, 2013 at 4:02 PM, Cédric Girard girard.ced...@gmail.comwrote: 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).
Re: [aur-general] VCS PKGBUILD and Pacman 4.1: increase epoch?
On Fri, 5 Apr 2013 15:11:40 -0400, luoli...@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.ced...@gmail.comwrote: 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.
Re: [aur-general] VCS PKGBUILD and Pacman 4.1: increase epoch?
On 5 April 2013 20:17, Doug Newgard scimmi...@outlook.com wrote: On Fri, 5 Apr 2013 15:11:40 -0400, luoli...@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.ced...@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?
Re: [aur-general] VCS PKGBUILD and Pacman 4.1: increase epoch?
On 5 April 2013 22:19, WorMzy Tykashi wormzy.tyka...@gmail.com wrote: On 5 April 2013 20:17, Doug Newgard scimmi...@outlook.com wrote: On Fri, 5 Apr 2013 15:11:40 -0400, luoli...@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.ced...@gmail.comwrote: 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? Oops. Forgot my reference. [0] https://wiki.archlinux.org/index.php/Arch_CVS_%26_SVN_PKGBUILD_guidelines
Re: [aur-general] VCS PKGBUILD and Pacman 4.1: increase epoch?
On Fri, 2013-04-05 at 22:20 +0100, WorMzy Tykashi wrote: On 5 April 2013 22:19, WorMzy Tykashi wormzy.tyka...@gmail.com wrote: On 5 April 2013 20:17, Doug Newgard scimmi...@outlook.com wrote: On Fri, 5 Apr 2013 15:11:40 -0400, luoli...@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.ced...@gmail.comwrote: 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? 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
Re: [aur-general] VCS PKGBUILD and Pacman 4.1: increase epoch?
On Fri, Apr 5, 2013 at 5:32 PM, Maxime Gauduin aluc...@gmail.com wrote: On Fri, 2013-04-05 at 22:20 +0100, WorMzy Tykashi wrote: On 5 April 2013 22:19, WorMzy Tykashi wormzy.tyka...@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
Re: [aur-general] VCS PKGBUILD and Pacman 4.1: increase epoch?
On Fri, Apr 5, 2013 at 11:41 PM, Jason St. John jstj...@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.
Re: [aur-general] VCS PKGBUILD and Pacman 4.1: increase epoch?
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 jstj...@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
Re: [aur-general] VCS PKGBUILD and Pacman 4.1: increase epoch?
On Fri, Apr 5, 2013 at 5:57 PM, Maxime Gauduin aluc...@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 jstj...@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
