[aur-general] Changes in Arch packaging standards

[Jerome Leclanche]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Fri, Dec 6, 2013 at 9:59 AM, Sven-Hendrik Haase <sh at lutzhaase.com> wrote:
> On 06.12.2013 10:45, Sergej Pupykin wrote:
>> At Fri, 06 Dec 2013 09:42:11 +0001,
>> Maxime Gauduin <alucryd at 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.
>
> 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_naming
>
> 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-----