Arch Linux Stable
Arch Linux Stable Branch/Snapshot
In reference to the discussion in this forum thread, the proposition has been put forth, initially by nagoola, to provide a stable branch or snapshot of the Arch Linux distribution.
To provide a stable branch for Arch Linux. This project shall serve to compliment and benefit Arch, the rolling release, and the community by conforming to The Arch Way and the K.I.S.S principle. It absolutely shall not and must not fork nor divide Arch, its community, nor code. Its existence must serve to unite, benefit and strengthen Arch, or it shall cease to be useful and therefore cease to exist. The stable branch is aimed to be used by servers or workstation machines, where minimal breakage is a must.
Why a stable branch? A general consensus has been formed, of the opinion that such a project will be advantageous in several ways:
1. For the stability of workstations/production machines: Arch is of the highest quality, and the rolling release model is very strong. However, it is the hope of this project's members that a stable branch may bring the added benefit of less breakage- "when you need it to just work."
2. Desktops/Personal machines: The convenience of upgrading with less breakage appeals to those who want less time fixing package breakage and more time using Arch for other, more productive tasks.
3. To widen the Arch Linux horizon by appealing to users who would benefit from Arch in a production environment, as well as offer more choice for existing users, the Arch spectrum will be broadened, quality enhanced, and reputation heightened.
In the context of the Arch Linux Stable Branch, 'stable' will mean: The ability to provide a smooth transition between upgrades with an absolute minimal measure of breakage, ideally none, while still remaining compatible with the current rolling release system. Over time stable shall also mean special versions of packages that have proven to run extremely well under production situations.
Communication is a must between all involved.
1. Project Leader - Delegate tasks and project direction.
2. Packagers - Choosing and handling packages to add to the snapshot repository.
3. Testers - Testing the stability of packages, logistics, and assistance.
4. Repository - Will require a server.
5. (Possibly) Scripting - submit a prototype script below, which can tweak the client (user) pacman.conf to ignorepkg= unstablepkg
The project volunteers must be dedicated and able to perform their responsibilities effectively and expeditiously. They must be capable of their assigned tasks, personable, and must keep each other informed of progress and issues as they arise.
Currently, the project has recruited these members:
- nagoola - Project Management tasks / Communication. Also programming or package maintenance.
- Nihathrael - Project Management / Programming / Documentation / Homepage / Package maintenance
- rxKaffee - Programming / Provides testing server / Package maintenance
- ibendiben - Coming soon, yet to decide
- Misfit138 - Wrote this page-I am above average with English. Below average at GNU/Linux.
- Basn - Packager
- sixty-four-bit - Packager
- AndyRTR - technical adviser, moderation / coordination if wanted/needed, maybe some packaging for core stuff
(Please add/remove your name as appropriate and state briefly what you are qualified to offer the project.)
We are currently setting up a test server for developers use, which will not be publicly announced. If you would like to join development please join #archlinux-stable at irc.freenode.net.
We are still looking for server-space that we can use to release the core-stable repository to the public. Please contact nagoola if you would like to offer hosting. The methodology section has been updated. Nihathrael 10:07, 15 January 2008 (EST)
After some discussion on IRC the following approach has been formed:
- Take a snapshot of the [core] repository once as a starting point. [Only packages from the groups "base" and some other hand picked packages will be used to start with (no "devel" for example)]
- Packages will be updated if one of the following happens:
- A major package update is released upstream, which has proven to be stable and bug/security fixed over time(~1-4 weeks)
- In case an upgrade needs human interaction the package is updated with the help of the project's own "secure-install-script", which will be explained in an extra section
- A minor package update is released upstream that provides bug or security fixes and is considered stable
- A major package update is released upstream, which has proven to be stable and bug/security fixed over time(~1-4 weeks)
- Critical packages like the kernel will be updated when approved by the maintenance team
Special programs needed:
- The source-code of all packages will be kept on the repository servers, to ensure that back-porting security/bug fixes is still possible, even if the upstream mirror does not provide the download of the version current to our repository. A script will be written to do this automatically. (Nihathrael will write this script)
- Secure-install-script: A "arch-stable" package will be created, that is put into the "holdpkg" line of pacman.conf. So in case it is updated, it will be updated before all other packages are updated. Now if we want to update a package that needs human interaction, for e.g. changes in the configuration, we will include this package into the arch-stable package and make arch-stable run a script, that will copy the package we wish to upgrade to a special folder (e.g. /var/mandatory_update), together with all documentation needed to safely update the package from hand. The script will then set the package we wish to upgrade to the "ignorepkg" line, so it will not be updated until updated by hand. The script will also leave a big message in the pacman.log, so the system administrator is notified and can update the package whenever he thinks the time is right.
By using this method, we can provide a repository that can provide critical updates if necessary, and that can still be updated with the pacman --noconfirm option, without the risk of breaking the system. (Nihathrael will test this method)
- Scripts to create lists containing all packages + versions + release-numbers + maintainers for easy overview of the current situation will be written (rxKaffee will do this)
As it is early in the project, all are invited to discuss.
IRC - irc.freenode.net #archlinux-stable
Crouse's Notes: To create a "stable" system, I currently auto-update nightly, although this could be changed to weekly to better control stability (IE: more time to find packages that break things).
Here is part of my auto-update script I use for my machines.... nothing earth shattering. I use a cronjob that does 2 things...
1st downloads a pacman.conf file. Anything that I don't want updated is not updated. Using the pacman.conf file, an assortment of options present themselves to help keep a system "stable". Examples:
IgnorePkg = kernel26 NoUpgrade = etc/lilo.conf boot/grub/menu.lst HoldPkg = pacman glibc
Again, nothing earth shattering, but it does allow me to keep packages that are breaking things, out of the system until proven trustworthy.
2nd runs an automatic update script (because I'm lazy and don't want to update a dozen plus machines all the time. Here is the code for that part:
#Pacman update and logging starts here echo " " 2>&1 >> /var/log/client.UPDATELOG echo "#############################################################" 2>&1 >> /var/log/client.UPDATELOG echo -ne "ARCH CLIENT UPDATE: " 2>&1 >> /var/log/client.UPDATELOG; echo `date +"%D %r"` 2>&1 >> /var/log/client.UPDATELOG echo "#############################################################" 2>&1 >> /var/log/client.UPDATELOG # Uncomment here if you want pacman to automatically update this machine pacman -Syu --noprogressbar --noconfirm 2>&1 >> /var/log/client.UPDATELOG # If you use lilo, remember to also uncomment the next line # /sbin/lilo 2>&1 >> /var/log/client.UPDATELOG
Sorry if this is a bit messy....... feel free to "clean-up" my wiki mess here at the end :)
These entries have been moved here because they are not the state of affairs, but provide good ideas on the project. Some are also kept for historical purposes.
Several different methods of achieving the project goal have been proposed-
1. Loosely basing the stable branch on Slackware packaging- expand to clarify, discuss.
a. Follow Slackware-Current 1. Kernel 18.104.22.168 b. Follow Slackware-Stable 1. Kernel 2.6.21
1b. The Rubix Linux idea was great. Not saying fork Arch, but we could take ideas, such as using 3 different kernels, one with grsecurity, one normal kernel. http://distrowatch.com/table.php?distribution=rubix Review: http://www.tuxmachines.org/node/4699
2. An rsync of core and extra every xx days, using the mirror as the package source. Longer periods of time (3-6 months) will bring unwanted issues. Once per month may be practical? Discuss.
3 . Instead of making one stable image, keep every major earlier version of packages, allowing the user choose which version of a package he should install.
4. Loosely basing the stable branch on the Frugalware methodology. (Expand to clarify.)
5. No stable "release" per se, but rather, stable packages.
6. Incorporating scripts to tweak ignorepkg= in pacman.conf on client (user) machines, until issues (upstream, configuration and otherwise) can be resolved, or instructions on fixage is secured. Submit a script here by pasting it below.
7. Package tagging system- whereby through testing and data gleaned from the Package Upgrade issues subforum, packages may be tagged as stable/unstable and appropriate action taken.
There could be a [core-stable] repository. This repository contains all the packages the normal [core] repo contains.
There are 3 possibilities/ideas:
There is a [core-stable] release every ~3 months (debatable), the packages in the [core-stable] are not updated to newer versions. Of course security fixes will have to be applied and added as updates. Every new release comes with new, but stable packages and a detailed documentation with fixes to known update problems for this release.
- Pretty much rock-solid core repository that is very unlikely to break during the 3 months it is used.
- A lot of work is required to back-port security fixes to the rather old packages.
- Probably a huge update is required from one release to another.
- No upstream improvements/new features are introduced during one release.
There is a [core-stable] repository that is continuously updated by maintainers. In order for a package to be updated, there should not be any known issues with it on the forums and IRC for about a week(debatable). Packages that are known to cause problems need to be checked and can be added if it's possible to remove the update problem with a script, that is then included in the update and automatically applied on install(Might be risky and a lot of work). Packages that can not be fixed to install correctly are kept away from updating until either a upstream fix is available and the problem disappears OR are released together will all other "problem-packages" in a ~3 month cycle, including detailed documentation on how to update the packages.
- Stable core repository with very few/none update problems.
- A stable repository, that is only 1 week behind the bleeding edge [core] repository. This way upstream improvements/new features are introduced shortly after release.
- Almost no need to back-port security fixes(only for "problem-packages")
- Higher risk of making the stable repository unstable, by updating packages that cause unknown problems.
- This is almost the exact same way it's done in Arch currently with the [testing] repository. So worst case is, you just shift the users form [core] to [core-stable] and [core] becomes your new [testing].
NOTE: This version does not imply a [core-stable], but more a [stable] repository, also containing important software from extra(e.g. server software, window managers, office suites, browsers, media players), needed in production environments.
This idea is a mix of a) and b). Packages are divided into groups, like "base", "office", "servers" and "media". "base" for example(e.g containing the kernel, glibc, etc. and the window managers) does not have to be frequently updated, as the user doesn't need new features on a stable system, but only needs security fixes. So these are updated as explained under a). "servers" is rather bound to be updated frequently, as new features and performance improvements are likely to be wanted by a server-administrator. These packages are then updated by the means of b). This is rather advanced and should not be the first thing to try.
All of these are only ideas and need detailed thoughts. So feel free to add/change anything you like.
Please feel free to add to or otherwise modify this project page and join the discussion at irc.freenode.net #archlinux-stable