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