[aur-general] Changes in Arch packaging standards
Hi, Bartłomiej Piotrowski proposed packaging standard changes: if there are 2 versions of some package foobar, then older version (1.0 for example) must be named as foobar1-1.0 and newer version (2.0 for example) must be named as foobar-2.0. I did not see such rule yet on https://wiki.archlinux.org/index.php/Arch_Packaging_Standards#Package_naming page, but my package openjpeg2 was silently removed with this reason however there are gtk* and wxgtk* packages that also violate this rule. I insist on giving me proof-link for this rule, including this rule into wiki (https://wiki.archlinux.org/index.php/Arch_Packaging_Standards#Package_naming) and renaming all packages according this rule. Or just leave it as is and stop dropping my packages. For more info see: https://bugs.archlinux.org/task/38016
On Fri, Dec 6, 2013 at 10:25 AM, Sergej Pupykin <ml@sergej.pp.ru> wrote:
Hi,
Bartłomiej Piotrowski proposed packaging standard changes: if there are 2 versions of some package foobar, then older version (1.0 for example) must be named as foobar1-1.0 and newer version (2.0 for example) must be named as foobar-2.0.
I did not see such rule yet on https://wiki.archlinux.org/index.php/Arch_Packaging_Standards#Package_naming page, but my package openjpeg2 was silently removed with this reason however there are gtk* and wxgtk* packages that also violate this rule.
I insist on giving me proof-link for this rule, including this rule into wiki (https://wiki.archlinux.org/index.php/Arch_Packaging_Standards#Package_naming) and renaming all packages according this rule.
Or just leave it as is and stop dropping my packages.
For more info see: https://bugs.archlinux.org/task/38016
I would change that rule a bit, because wxgtk is a special case. The 2.9 branch is a devel branch, keeping wxgtk for the stable branch and adding a suffix for the devel branch makes sense. Speaking of wxgtk, now that 3.0.0 is out, we will most likely need to get rid of wxgtk29 and create a legacy wxgtk28 package. Anyway, imho the rule should be: use plain name for the latest stable release, and add the appropriate suffix (usually 1 or 2 digits) for any other release. Cheers, -- Maxime
At Fri, 06 Dec 2013 09:42:11 +0001, Maxime Gauduin <alucryd@gmail.com> wrote:
I would change that rule a bit, because wxgtk is a special case. The 2.9 branch is a devel branch, keeping wxgtk for the stable branch and adding a suffix for the devel branch makes sense. Speaking of wxgtk, now that 3.0.0 is out, we will most likely need to get rid of wxgtk29 and create a legacy wxgtk28 package.
Anyway, imho the rule should be: use plain name for the latest stable release, and add the appropriate suffix (usually 1 or 2 digits) for any other release.
I prefer leave all things as is without any new rules. There are packages that have multiple stable branches.
On 06.12.2013 10:45, Sergej Pupykin wrote:
I would change that rule a bit, because wxgtk is a special case. The 2.9 branch is a devel branch, keeping wxgtk for the stable branch and adding a suffix for the devel branch makes sense. Speaking of wxgtk, now that 3.0.0 is out, we will most likely need to get rid of wxgtk29 and create a legacy wxgtk28 package.
Anyway, imho the rule should be: use plain name for the latest stable release, and add the appropriate suffix (usually 1 or 2 digits) for any other release. I prefer leave all things as is without any new rules. There are
At Fri, 06 Dec 2013 09:42:11 +0001, Maxime Gauduin <alucryd@gmail.com> wrote: packages that have multiple stable branches.
I went ahead and proposed a new rule because I also think this should be in the guidelines: https://wiki.archlinux.org/index.php/Talk:Arch_Packaging_Standards#Package_n... Comments? <https://wiki.archlinux.org/index.php/Talk:Arch_Packaging_Standards#Package_naming>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Fri, Dec 6, 2013 at 9:59 AM, Sven-Hendrik Haase <sh@lutzhaase.com> wrote:
On 06.12.2013 10:45, Sergej Pupykin wrote:
I would change that rule a bit, because wxgtk is a special case. The 2.9 branch is a devel branch, keeping wxgtk for the stable branch and adding a suffix for the devel branch makes sense. Speaking of wxgtk, now that 3.0.0 is out, we will most likely need to get rid of wxgtk29 and create a legacy wxgtk28 package.
Anyway, imho the rule should be: use plain name for the latest stable release, and add the appropriate suffix (usually 1 or 2 digits) for any other release. I prefer leave all things as is without any new rules. There are
At Fri, 06 Dec 2013 09:42:11 +0001, Maxime Gauduin <alucryd@gmail.com> wrote: packages that have multiple stable branches.
I went ahead and proposed a new rule because I also think this should be in the guidelines: https://wiki.archlinux.org/index.php/Talk:Arch_Packaging_Standards#Package_n...
Comments? <https://wiki.archlinux.org/index.php/Talk:Arch_Packaging_Standards#Package_naming>
Sensitive topic: Why doesn't arch support multiple versions for the same packages? Whenever it's brought up, there's always the answer that Arch is a rolling release (and we're all happy with that). But pretty obviously there are cases where multiple versions are useful and needed. It strikes me that all of this would be a non-issue if maintainers were able to make a certain set of versions available for packages, and users were able to install multiple versions of the same package. (Incidentally it would also make rollbacks easier if the previous package is kept for a couple of days and solve a common complaint against Arch). If the only issue is manpower I'm more than happy to work on it and send patches. (Ok there's some personal reasons I'd like this; I discussed with the developers of a couple of domain-specific packaging apps about compatibility with pacman and this is one of the major roadblocks... a debate for another day) J. Leclanche -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQJ8BAEBCgBmBQJSoaU6XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxNjk3MDRDNkZCNDkwQzY4OTJDN0YyM0Mz N0UwQUYxRkRBNDhGMzczAAoJEDfgrx/aSPNztMoP/jOcLzTFa5SmyZV+d7Yw+H6j bhxcPoJPuUqMdkOJSc7QhLSzPl8nkxTuIsshRXvXhfpgU/bq9vSKmPH6E718kzHQ s25R3DVY8pJRfHk8j8cc88DOZrIsAbRU0xsCfI8AzB9RmJwZLQzHoshovEqlRrDo grCQV6u0mIq1Y4n3Uc2u9NFt7H2s6MQuB6TQrcNY+K0Mmkk8056RkGmrcx4FibiH cvqV9jhFdhrwb/nSBYXt6vl1zPMNMUxSJdrBT5tSAukdnpfrfH6fvUE4gfPYUHby iWcABP9qdeIoUjSKVNQfR9FyyqTI/tPJLSvejqIvzV87PewGpdc2WSgWZU9LpOvo GxCR7dc9ppLP8NEoYr6bLiAZnOD3mUl4P7WCsfh2CJ/CAUSRLHv9aKlDXddVAGtW 5IsGgnJOQkHxjCoLf91BTiMFup5WrYXz65SjQ0iZo58ZnhgNuoisp0EvtvNX4toR PtSe9nvlJnmPF1bgXOQaV5768EBgT1buGaEb6pVQjayg9Q3kheyrsH+kMpR+rV5X h+2ALQn9/HBUmpav2I1+n4lAvVUpe75UFofQBfTJs1ldIpgvaVSM0FnPNjdgF1qs V0KUtkb1MI4v80wyK8gl6N1HSMVYqnsxW8xBweCVdy/ai7pUQ9ZbpEN24BuO7zwu +LjdYrRMPiuOjYsw2izJ =lytr -----END PGP SIGNATURE-----
At Fri, 6 Dec 2013 10:22:35 +0000, Jerome Leclanche <adys.wh@gmail.com> wrote:
Sensitive topic: Why doesn't arch support multiple versions for the same packages?
Another sensitive topic is removing packages without notification refering to nonexistent rule. WTF? :S
On 06.12.2013 11:31, Sergej Pupykin wrote:
At Fri, 6 Dec 2013 10:22:35 +0000, Jerome Leclanche <adys.wh@gmail.com> wrote:
Sensitive topic: Why doesn't arch support multiple versions for the same packages? Another sensitive topic is removing packages without notification refering to nonexistent rule.
WTF? :S
It should be common courtesy to notify but let us focus on the documentation issue that you mentioned for now. Bartłomiej should have notified you before deleting. I have proposed a guideline change that should clear these things up for next time.
On 12/06/13 at 10:22am, Jerome Leclanche wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Fri, Dec 6, 2013 at 9:59 AM, Sven-Hendrik Haase <sh@lutzhaase.com> wrote:
On 06.12.2013 10:45, Sergej Pupykin wrote:
I would change that rule a bit, because wxgtk is a special case. The 2.9 branch is a devel branch, keeping wxgtk for the stable branch and adding a suffix for the devel branch makes sense. Speaking of wxgtk, now that 3.0.0 is out, we will most likely need to get rid of wxgtk29 and create a legacy wxgtk28 package.
Anyway, imho the rule should be: use plain name for the latest stable release, and add the appropriate suffix (usually 1 or 2 digits) for any other release. I prefer leave all things as is without any new rules. There are
At Fri, 06 Dec 2013 09:42:11 +0001, Maxime Gauduin <alucryd@gmail.com> wrote: packages that have multiple stable branches.
I went ahead and proposed a new rule because I also think this should be in the guidelines: https://wiki.archlinux.org/index.php/Talk:Arch_Packaging_Standards#Package_n...
Comments? <https://wiki.archlinux.org/index.php/Talk:Arch_Packaging_Standards#Package_naming>
Sensitive topic: Why doesn't arch support multiple versions for the same packages? Whenever it's brought up, there's always the answer that Arch is a rolling release (and we're all happy with that). But pretty obviously there are cases where multiple versions are useful and needed. It strikes me that all of this would be a non-issue if maintainers were able to make a certain set of versions available for packages, and users were able to install multiple versions of the same package. (Incidentally it would also make rollbacks easier if the previous package is kept for a couple of days and solve a common complaint against Arch).
Multiple versions are annoying, not only does it mean more overhead for packaging it also doesn't make much sense for packages like Firefox, etc. Most arch users want to use the latest version, if something breaks you can always rollback with pacman -U or ( ARM ). Supporting multiple versions of libraries seem unfeasable, how would we handle rebuilds etc. Multiple versions of for example Apache aren't a problem for me if they differ that much. Also your approach of multiple versions at the same time isn't as easy as it looks I bet. P.S. Please use the S/MIME option for GnuPGP instead of inline. -- Jelle van der Waa
Jerome Leclanche wrote:
Sensitive topic: Why doesn't arch support multiple versions for the same packages? Whenever it's brought up, there's always the answer that Arch is a rolling release (and we're all happy with that). But pretty obviously there are cases where multiple versions are useful and needed. It strikes me that all of this would be a non-issue if maintainers were able to make a certain set of versions available for packages, and users were able to install multiple versions of the same package.
Jelle van der Waa wrote:
Multiple versions are annoying, not only does it mean more overhead for packaging it also doesn't make much sense for packages like Firefox, etc. Most arch users want to use the latest version, if something breaks you can always rollback with pacman -U or ( ARM ).
Supporting multiple versions of libraries seem unfeasable, how would we handle rebuilds etc. Multiple versions of for example Apache aren't a problem for me if they differ that much.
Also your approach of multiple versions at the same time isn't as easy as it looks I bet.
Multiple package versions make sense when there are multiple upstream branches that are both incompatible and simultaneously supported. Firefox doesn't meet this criterion because each new version supersedes the previous version. This is the case for most packages. Python exists in 2 versions for an indefinite transition period due to backwards incompatibility and continued support for Python 2. Python2 and Python 3 are distinct dialects of the same language with different uses. Libraries may also meet this criterion (e.g. GnuPG 2 and 1). There are basically 2 scenarios to consider: parallel branches and transition branches. Parallel branches are actively developed upstream without any plan for one to supersede the other(s). In that case we should include a defining suffix for each package to indicate the branch (foo2, foo3) and track the latest stable version of each. Transition branches provide legacy support while waiting for everyone to catch up. In that case the current policy is to package the legacy branches with a defining suffix (e.g. bar2) and the main stable branch without a suffix (e.g. bar). Unstable development branches also get defining suffixes. Personally I think a better policy would be to add a defining suffix to the main stable branch package when future incompatible branches may be expected and when the current main stable branch is clearly distinguished, but I admit that this is not always easy to determine. (I'm not giving a example because I don't want to derail the topic with bickering about a specific package). Jerome Leclanche wrote:
(Incidentally it would also make rollbacks easier if the previous package is kept for a couple of days and solve a common complaint against Arch).
For rolling back upgrades, you are supposed to keep the old packages in your cache yourself so that you can roll back if necessary. Some people even keep multiple versions of certain packages. There are numerous tools for managing the local package cache and rolling back to previous package sets. The Arch Linux Rollback Machine (ARM) has also been revived, so there really is no reason to clutter the mirrors with outdated packages.
Anyway, imho the rule should be: use plain name for the latest stable release, and add the appropriate suffix (usually 1 or 2 digits) for any other release. This is wonderfully simple and straightforward. It's also current practice. Let's keep using it.
There are basically 2 scenarios to consider: parallel branches and transition branches. Can you give an example of the "parallel branches" scenario? Even Python 2, a poster child for long-term backwards compatibility, is still a "transition branch". I can't think of any examples of the "parallel branches" scenario, and if that scenario does not exist, then this entire debate over packaging standards is a moot point.
I think a better policy would be to add a defining suffix to the main stable branch package when future incompatible branches may be expected and when the current main stable branch is clearly distinguished The main stable branch of a project is *always* going to be incompatible with future versions. Django 1.6 will be incompatible with 1.7; Lighttpd 1.4 will be incompatible with version 1.5; and so on. That's just the nature of software.
On Fri, Dec 6, 2013 at 4:41 AM, Maxime Gauduin <alucryd@gmail.com> wrote:
On Fri, Dec 6, 2013 at 10:25 AM, Sergej Pupykin <ml@sergej.pp.ru> wrote:
Hi,
Bartłomiej Piotrowski proposed packaging standard changes: if there are 2 versions of some package foobar, then older version (1.0 for example) must be named as foobar1-1.0 and newer version (2.0 for example) must be named as foobar-2.0.
I did not see such rule yet on https://wiki.archlinux.org/index.php/Arch_Packaging_ Standards#Package_naming page, but my package openjpeg2 was silently removed with this reason however there are gtk* and wxgtk* packages that also violate this rule.
I insist on giving me proof-link for this rule, including this rule into wiki (https://wiki.archlinux.org/index.php/Arch_Packaging_ Standards#Package_naming) and renaming all packages according this rule.
Or just leave it as is and stop dropping my packages.
For more info see: https://bugs.archlinux.org/task/38016
I would change that rule a bit, because wxgtk is a special case. The 2.9
branch is a devel branch, keeping wxgtk for the stable branch and adding a suffix for the devel branch makes sense. Speaking of wxgtk, now that 3.0.0 is out, we will most likely need to get rid of wxgtk29 and create a legacy wxgtk28 package.
Exact. I was waiting so that more packages work with the new wxgtk. I'll start the rebuild in January after the holidays. Eric
Anyway, imho the rule should be: use plain name for the latest stable release, and add the appropriate suffix (usually 1 or 2 digits) for any other release.
Cheers, -- Maxime
On Fri, Dec 6, 2013 at 10:25 AM, Sergej Pupykin <ml@sergej.pp.ru> wrote:
Hi,
Bartłomiej Piotrowski proposed packaging standard changes: if there are 2 versions of some package foobar, then older version (1.0 for example) must be named as foobar1-1.0 and newer version (2.0 for example) must be named as foobar-2.0.
I did not see such rule yet on https://wiki.archlinux.org/index.php/Arch_Packaging_Standards#Package_naming page, but my package openjpeg2 was silently removed with this reason however there are gtk* and wxgtk* packages that also violate this rule.
I insist on giving me proof-link for this rule, including this rule into wiki (https://wiki.archlinux.org/index.php/Arch_Packaging_Standards#Package_naming) and renaming all packages according this rule.
Or just leave it as is and stop dropping my packages.
For more info see: https://bugs.archlinux.org/task/38016
I don't think there should be such rule at all, because from my point of view having multiple versions of software should be avoided if possible. For the remaining cases I'd leave it up to the maintainer. The reason is that there may be some custom when referencing to various versions. Eg. in GTK world, GTK 1 was usually referenced as just GTK, then GTK 2 was referenced as GTK 2 etc. which the current naming reflects nicely. For the libs where there is no such custom and especially if the older version is introduced only because of some minor compatibility issues (eg libpng and libjpeg, which has some minor incompatibilities but it's nothing like a big rewrite between GTK 2 and GTK 3) I would prefer having the current version without any version suffix and add it only to the older version, like it's done with libpng. But there's one thing that I would like to avoid altogether is using suffixes that doesn't indicate the version like the -compat suffix in ffmpeg-compat. What should the maintainer do if he needed another version? Should they create -compat and compat2 packages? Lukas
On 6 December 2013 17:25, Sergej Pupykin <ml@sergej.pp.ru> wrote:
Bartłomiej Piotrowski proposed packaging standard changes:
Where is this proposal? I think he simply meant that it is the current practice.
if there are 2 versions of some package foobar, then older version (1.0 for example) must be named as foobar1-1.0 and newer version (2.0 for example) must be named as foobar-2.0.
That's the standard case, yes, since we strive to keep in line with upstream. If upstream says "the latest release of FOO" and not "the latest release of FOO2", we simply retain the name and relegate the older version to a suffixed package.
I did not see such rule yet on https://wiki.archlinux.org/index.php/Arch_Packaging_Standards#Package_naming
It's not a documented rule, but you have seen this with Python.
but my package openjpeg2 was silently removed with this reason
That is simply wrong. We are not known to do this, no matter how inactive someone else is. A notification is always the right way.
I insist on giving me proof-link for this rule, including this rule into wiki (https://wiki.archlinux.org/index.php/Arch_Packaging_Standards#Package_naming) and renaming all packages according this rule.
Sven's proposal should get that rolling. -- GPG/PGP ID: C0711BF1
participants (10)
-
Eric Bélanger
-
Jelle van der Waa
-
Jeremy Audet
-
Jerome Leclanche
-
Lukas Jirkovsky
-
Maxime Gauduin
-
Rashif Ray Rahman
-
Sergej Pupykin
-
Sven-Hendrik Haase
-
Xyne