[aur-general] Changes in Arch packaging standards

[Xyne]

> 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.