Difference between revisions of "Arch Linux Stable"

From ArchWiki
Jump to: navigation, search
m (Project Volunteers)
Line 52: Line 52:
 
* Nihathrael - Project Management / Programming / Documentation / Homepage / Package maintenance
 
* Nihathrael - Project Management / Programming / Documentation / Homepage / Package maintenance
 
* rxKaffee - Programming / Provides testing server / Package maintenance
 
* rxKaffee - Programming / Provides testing server / Package maintenance
* ibendiben - Coming soon, yet to decide
+
* ibendiben - Testing, later hopefully package maintenance and documentation
 
* Misfit138 - Wrote this page-I am above average with English. Below average at GNU/Linux.
 
* Misfit138 - Wrote this page-I am above average with English. Below average at GNU/Linux.
 
* Basn - Packager
 
* Basn - Packager

Revision as of 14:16, 28 January 2008

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. The stable branch is aimed to be used by servers or workstation machines, where minimal breakage is a must.

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.

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. Over time stable shall also mean special versions of packages that have proven to run extremely well under production situations.

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

Communication

IRC - irc.freenode.net #archlinux-stable
Mailing list - archlinux-stable-request@freelists.org Send e-mail with the subject 'subscribe'
or view the archive here: http://www.freelists.org/archives/archlinux-stable/

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.
  • Nihathrael - Project Management / Programming / Documentation / Homepage / Package maintenance
  • rxKaffee - Programming / Provides testing server / Package maintenance
  • ibendiben - Testing, later hopefully package maintenance and documentation
  • 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
  • my64
  • hussam

(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 to 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. Please refer to the mailing list for newest information.

Methodology

section has been modified
Nihathrael 10:07 am, 15 January 2008 (EST)
sixty-four-bit 10:03 pm, 15 January 2008 (EST): satisfy concerns from andyrtr and ise
Please advise on this issue.
Nihathrael 07:15, 24 January 2008 (EST): Mark as outdated, added mailing list archive link.

PLEASE NOTE: Ideas are under a lot of development currently, therefor the wiki entry does not reflect the current situation. We will update the wiki with new information as soon as a solid idea has been formed. Please review the mailing list(http://www.freelists.org/archives/archlinux-stable/) for newest information for now.

OUTDATED: After some discussion on IRC the following approach has been formed:

  1. Take a snapshot of the [core] repository once as a starting point. [Only packages from the group "base" will be considered. At first some packages will be removed and be added as needed later on. (no "devel" for example)]

  2. Then at certain time intervals, say 12 months, another snapshot of [core] will be taken. This snapshot will be exactly one year to the date of the previous snapshot. The development team will go over the new snapshot and check the differences between the recent snapshot and the previous one. The development team will then come up with a plan on what packages need to be upgraded to become 'current' but yet still stable. Then this will become the plan for the 'forced' upgrade to the next stable release.

    • Packages will be updated if for one of the following reasons:
      1. A major package update is released upstream, which has proven to be stable and bug/security fixed over time
        • 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 later, in section below.

      2. A minor package update is released upstream that provides a bug/security fix and is considered stable.

      3. All upgrades will be considered critical from snapshot to snapshot, but any security/bug fix in between 'forced' upgrade will work like they do in arch now. Once the security/bug fix is deemed 'stable' then it will be released via a normal pacman upgrade.



This same methodology can be expanded to other repositories. Andyrtr stated that each release would have to have all its packages rebuilt each snapshot, because rolling release updates in between snapshots would 'by design' break other packages. Therefor we would need to do snapshots for other repositories and maintain the programs in those repositories as we would do [core-stable] as I understand it. Andyrtr, please advise on this issue...

Special programs needed: These are just the early design goals, please join the discussion IRC - irc.freenode.net #archlinux-stable

  1. The source-code of all packages will be kept on the repository servers. This will ensure that back-porting security/bug fixes is still possible, even if the upstream mirror does not provide the version current to our repository. A script will be written to do this automatically. (Nihathrael will write this script)

  2. Secure-install-script: A "arch-stable" package will be created that is put into the "holdpkg" line of pacman.conf (holdpkg = arch-stable). In case this package is updated, it will be updated before all other packages. Now if we want to update a package that needs human interaction, for e.g. changes in the system configuration, we will include this package into the arch-stable package and make arch-stable run a script. The script 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 by hand. Then the script will set the package we wish to upgrade to the "ignorepkg" line so it will not be updated until a human has specified this action. This ensures that any package that could potentially break your system will require your full attention. This script will then also leave a big message in the pacman.log so the system administrator is notified and can update the package whenever he feels the time is right.
    By using this method we can offer a repository that can still provide critical updates if necessary and can still be updated by the pacman --noconfirm option without the risk of breaking the system. (Nihathrael will test this method)

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

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


Old Entries

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.

Methodology Possibilities

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.

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