Linux distributions could be divided in two categories :
- Rolling release system : unstable, always recent packages (up-to-date)
- "Stable" release system : stable, old packages (slow evolution)

I think we need something more powerful, more flexible, and ArchLinux is in my opinion a distribution that could do this.
Rolling release system is really interesting, but parts of a system shouldn't be always replaced by the latest (unstable) version.

A few exemples, based on what I use :
- Firefox (or other common software) : you may want to wait for plugins being updated for the new version, or just want to choose when leaving 2.0.x for 3.0.x
- Eclipse (or other tool) : new versions are generally full of bugs, interface or features could have changed, the version changes shouldn't be "forced"
- Java/Python (or other environments) : there are incompatible changes between versions, when you have an environment installed you don't want its version to change (or just if *you* decide to change it (and test it with all your programs using this environment))
- Xorg (or other system tool) : old driver compatibility problems, change in configuration files format, ... (example : Xorg's last major version)
- ...
! Another thing about ArchLinux as a base for different usages : for a client, we might need latest versions (or not...), but for a server, we need stable software too.

Note : I know we are not forced to update packages, but as there is only one branch for a package, we can't stick to a version a of package, which is not maintained anymore by ArchLinux (or any repository). For instance example if I use mypackage-1.0.3 and it is replaced by mypackage-1.1.0, I can't get mypackage-1.0.x packages anymore. And if I want to "remain" on 1.0.x branch, I can't do automatic updates since I need verifying the version number of every package I want to be stable.

The best way I can think to achieve this is based on rolling release system, with more than one branch per package.

Basic features needed for this :
- Maintain several parallel branches for a package
- Releases including major changes are on separate branches (exemple : firefox-3.0.x, firefox-3.1.x, eclipse-3.2.x, eclipse-3.3.x, python-2.6.x, python-3.0.x, ...)
- Releases including bugs/security/... fixes are on the same branch (firefox-3.0.7 replace firefox-3.0.6)
- Possibility to update a package with the newer release or with the newer release on the current branch (<=> "stable" update)
(default should be to update with the newer version, which is consistent with Arch current behaviour)
- Possibility to mark a package as stuck to the current branch ; in this case, default update of a package should do an update on the branch
- When doing a full update (-Su), pacman should use the marker to decide between updating to latest release or juste to latest release on the branch ; this allow making stable updates, (almost) without danger : packages you want to keep stable remain on their branch, others are updated with later package release [in fact this is the same as the two previous points, but for total update]
- Possibility to change the branch on which a package is stuck
- Mark branches that are not maintained anymore (maybe with an indication of who decided to cut this branch : Arch or the developpers of this program) ; Pacman could print a warning about that while trying to update the package

Another related problem : while using an environment with several incompatible versions (Java, Python, ...), the possibility to install several parallel branches would be very useful (several versions installed in directories whose names are those of branches).


I hope this quite long message won't be too hard to read. I think Arch is a great distribution just needing the ability to decide something should be stable instead of recent to be fully customizable.


Syll