Revision as of 02:11, 5 January 2008

Contents

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

Requirements

1. Project Leader - for delegating tasks and project direction.

2. Packagers - for choosing and handling packages to add to the snapshot repo.

3. Testers - for testing the stability of packages, logistics, and assistance.

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.

Methodology

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 put on hold

HoldPkg = pacman glibc

Again, nothing earth shattering, but it does allow me to keep packages that are breaking things out of my systems.

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: