Arch Linux Stable

From ArchWiki
Revision as of 14:17, 10 January 2008 by Anonymo (Talk | contribs) (Methodology)

Jump to: navigation, search

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.

GOAL

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.

Concept

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.

4.

Definition

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.

Requirements

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

Project Volunteers

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.

ibendiben - Coming soon, yet to decide

my64

hussam

Nihathrael

Misfit138 - Wrote this page-I am above average with English. Below average at GNU/Linux.

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

Project Status

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.

Methodology

Several different methods of achieving the project goal have been proposed-

They include:

1. Loosely basing the stable branch on Slackware packaging- expand to clarify, discuss.

  a.  Follow Slackware-Current
      1.  Kernel 2.6.23.12
  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.

As it is early in the project, all are invited to discuss.

IRC- irc.freenode.net #archlinux-stable

  • Prototype Scripts

Growth

The project must start somewhere.

  • Scope

A small, manageable stable snapshot of the core repo may be the best way to begin work; adding as future manpower allows until a complete stable system is achieved.

Sandbox

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 :)

Release-Cycle Ideas

There could be a [core-stable] repository. This repository contains all the packages the normal [core] repo contains.
There are 3 possibilities/ideas:

Version A

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

  • Pretty much rock-solid core repository that is very unlikely to break during the 3 months it is used.

Disadvantages:

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

Version B

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

  • 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")

Disadvantages:

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

Version C

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.