https://wiki.archlinux.org/api.php?action=feedcontributions&user=Sixty-four-bit&feedformat=atomArchWiki - User contributions [en]2024-03-28T16:37:03ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Xmonad&diff=35649Xmonad2008-01-26T18:40:47Z<p>Sixty-four-bit: /* Introduction */</p>
<hr />
<div>= Introduction =<br />
<br />
[http://xmonad.org/ xmonad] is a tiling window manager for X. Windows are arranged automatically to tile the screen without gaps or overlap, maximizing screen use. Window manager features are accessible from the keyboard: a mouse is optional. <br />
<br />
xmonad is written, configured and extensible in [http://haskell.org/ Haskell]. Custom layout algorithms, key bindings and other extensions may be written by the user in config files. <br />
<br />
Layouts are applied dynamically, and different layouts may be used on each workspace. Xinerama is fully supported, allowing windows to be tiled on several physical screens.<br />
<br />
For more information, please visit the xmonad website: http://xmonad.org/<br />
<br />
= Installation =<br />
<br />
xmonad is currently available in the community repo. A build for the current development snapshot (darcs) is in the [http://aur.archlinux.org/ aur]. The following instructions are for xmonad-darcs, the development snapshot.<br />
<br />
== Development Version (xmonad-darcs) ==<br />
<br />
The xmonad-darcs development release requires 3 separate packages available from AUR (install them in the following order):<br />
<br />
* [http://aur.archlinux.org/packages.php?do_Details=1&ID=13750&O=0&L=0&C=0&K=xmonad&SB=n&SO=a&PP=25&do_MyPackages=0&do_Orphans=0&SeB=nd haskell-x11-darcs] - haskell bindings to the X11 graphics library<br />
* [http://aur.archlinux.org/packages.php?do_Details=1&ID=10593&O=0&L=0&C=0&K=xmonad&SB=n&SO=a&PP=25&do_MyPackages=0&do_Orphans=0&SeB=nd xmonad-darcs] - the core window manager<br />
* [http://aur.archlinux.org/packages.php?do_Details=1&ID=13652&O=0&L=0&C=0&K=xmonad&SB=n&SO=a&PP=25&do_MyPackages=0&do_Orphans=0&SeB=nd xmonad-contrib-darcs] - contributed extensions providing custom layouts, configurations, etc.<br />
<br />
= Configuration =<br />
<br />
== Starting xmonad ==<br />
To start xmonad automatically, simply add the command '''xmonad''' to your startup script (e.g. ~/.xinitrc). GDM and KDM users can create a new session file and then select xmonad from the appropriate Session menu.<br />
<br />
== Configuring xmonad ==<br />
<br />
As of version 0.5 (currently in development), xmonad has moved to a user-based configuration structure. Users can now modify, override or extend the default settings with the ~/.xmonad/xmonad.hs configuration file. Recompiling is now done on the fly, with the Mod+q shortcut; no longer must you rebuild and reinstall packages just to change your preferences.<br />
<br />
Because the xmonad configuration file is written in Haskell, non-programmers may have a difficult time adjusting settings. For detailed HOWTO's and example configs, we refer you to the following resources:<br />
<br />
* [http://gorgias.mine.nu/xmonad/xmonad-contrib/Documentation.html Official xmonad documentation project]<br />
* [http://haskell.org/haskellwiki/Xmonad/Config_archive xmonad config archive]<br />
* [http://haskell.org/haskellwiki/Xmonad/Frequently_asked_questions xmonad FAQ]<br />
<br />
== Exiting xmonad ==<br />
To end the current xmonad session, press Mod+SHIFT+q (Mod being ALT by default).<br />
<br />
= Tips & Tricks =<br />
== Launching programs ==<br />
By default, xmonad uses [[dmenu]] (installed as a dependency) for launching applications. dmenu can be invoked by pressing Mod+p (Mod being the ALT key by default). Enter the first few characters of the program and dmenu will narrow down the choices (press TAB for auto-completion). <br />
<br />
For example, to launch Firefox press Alt+p to bring up dmenu, then type ' ''fir'' '. You will see ''firefox'' as one of the options; simply press the Enter key to load.<br />
<br />
== Making room for conky or tray apps ==<br />
xmonad can be configured to leave space at the top or bottom of your screen for background applications like Conky or trayer. To do so, open the Config.hs file in your favourite editor and change the ''defaultGaps'' value:<br />
defaultGaps = [(0,0,0,0)]<br />
The fields are: top, bottom, left, right. So, to leave a 15 pixel gap at the top and a 24 pixel gap along the bottom would look like this:<br />
defaultGaps = [(15,24,0,0)]<br />
<br />
Or, wrap your layouts with avoidStruts from XMonad.Hooks.ManageDocks for the fitting to happen automatically:<br />
layoutHook = avoidStruts (tiled Tall ||| ...<br />
manageHook = manageHook defaultConfig <+> manageDocks<br />
<br />
If you ever want to toggle the gaps the action is<br />
,((modMask x, xK_b ), sendMessage ToggleStruts)<br />
<br />
== Dzen & conky-cli ==<br />
[http://aur.archlinux.org/packages.php?do_Details=1&ID=11884&O=0&L=0&C=0&K=conky-cli&SB=n&SO=a&PP=25&do_MyPackages=0&do_Orphans=0&SeB=nd conky-cli], a stripped-down version of the Conky status utility, can be used to pipe information directly to dzen for output in a statusbar. The following example displays the the loadavg values in red and the current time in the default dzen foreground colour:<br />
<br />
'''~/.conkyrc:'''<br />
background no<br />
out_to_console yes<br />
update_interval 1.0<br />
total_run_times 0<br />
use_spacer no<br />
<br />
TEXT<br />
^fg(#ff0000)${loadavg 1 2 3} ^fg()${time %a %b %d %I:%M%P}<br />
<br />
<br />
'''~/bin/dzconky:'''<br />
<br />
#!/bin/sh<br />
<br />
FG='#aaaaaa'<br />
BG='#1a1a1a'<br />
FONT='-*-terminus-*-r-normal-*-*-120-*-*-*-*-iso8859-*'<br />
conky | dzen2 -e '' -h '16' -w '600' -ta r -fg $FG -bg $BG -fn $FONT<br />
<br />
Simply execute ''dzconky'' in your startup scripts.<br />
<br />
= Other Resources =<br />
[http://xmonad.org/ xmonad] -- The official xmonad website<br />
<br />
[http://xmonad.org/tour.html xmonad: a guided tour]<br />
<br />
[[dzen]] -- A general purpose messaging and notification program<br />
<br />
[[dmenu]] -- A dynamic X menu for the quick launching of programs</div>Sixty-four-bithttps://wiki.archlinux.org/index.php?title=Mirrors&diff=35280Mirrors2008-01-20T08:25:53Z<p>Sixty-four-bit: /* Enabling your favorite mirror */</p>
<hr />
<div>[[Category:Package management (English)]]<br />
[[Category:HOWTOs (English)]]<br />
== Enabling your favorite mirror ==<br />
<br />
The default pacman configuration for ''core'' looks like this:<br />
<br />
[core]<br />
Include = /etc/pacman.d/core<br />
<br />
If you want to use the HostEurope mirror as your default mirror, just add it before the <tt>Include</tt> line:<br />
<br />
[core]<br />
Server = <nowiki>ftp://ftp.hosteurope.de/mirror/ftp.archlinux.org/core/os/i686</nowiki><br />
Include = /etc/pacman.d/core<br />
<br><br />
'''edit:''' The release of pacman 3.1 introduced the /etc/pacman.d/mirrorlist with the variable $repo, no need to maintain separate list for each repository.<br />
<br />
Pacman will now try to connect to this mirror first. You can do the same for ''testing'', ''extra'', ''community'' and ''unstable''.<br />
<br />
'''Use the same mirror for all repositories. Otherwise packages may get installed that are incompatible to each other (like kernel26 from ''core'' and another (older) kernel module from ''extra'').'''<br />
<br />
== Mirror List ==<br />
<br />
This is a list of all known ArchLinux mirrors, that's more up to date than the [http://www.archlinux.org/download/ official download page] or the [http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/base/pacman/ files in <tt>/etc/pacman.d/</tt>]. If you know of a mirror that is not listed, please add it. Mirrors which are no longer updated or have been unavailable for a long time can be deleted.<br />
<br />
Here is a hint to check just how up-to-date your chosen mirror is:<br />
# pick a server and browse to "extra/os/"<br />
# load [http://www.archlinux.org/ ArchLinux.org] in another tab or window<br />
# compare the last-modified date of the "i686" directory on the mirror to the "Extra" date on the homepage, in the "Package Repositories" box to the right.<br />
<br><br />
Many sites also provide http service, but keep in mind that pacman relies on ftp to determine if a repository got updated. With http it fetches the repository database each time you run <tt>pacman -Sy</tt>, even if it didn't change since the last run.<br />
<br />
'''Attention: Do not add new mirrors to the list below. If you want your mirror to be added to official list - file a feature request. In the meantime add it to the "Unofficial mirrors" list at the end of this page.'''<br />
<br />
=== Australia ===<br />
*ftp://mirror.pacific.net.au/linux/archlinux/ <sub>[http://mirror.pacific.net.au/linux/archlinux/ http]</sub><br />
*ftp://mirror.aarnet.edu.au/pub/archlinux/ <sub>[http://mirror.aarnet.edu.au/pub/archlinux/ http]</sub><br />
<br />
=== Austria ===<br />
*ftp://gd.tuwien.ac.at/opsys/linux/archlinux/ <sub>[http://gd.tuwien.ac.at/opsys/linux/archlinux/ http]</sub><br />
*ftp://mirror.internode.on.net/pub/archlinux/ <sub>[http://mirror.internode.on.net/pub/archlinux/ http]</sub><br />
<br />
=== Belgium ===<br />
*ftp://ftp.belnet.be/mirror/archlinux.org/ <sub>[http://ftp.belnet.be/mirror/archlinux.org/ http]</sub><br />
<br />
=== Brazil ===<br />
*ftp://archlinux.c3sl.ufpr.br/archlinux/ <sub>[http://archlinux.c3sl.ufpr.br/ http]</sub><br />
<br />
=== Czech Republic ===<br />
*ftp://ftp.sh.cvut.cz/MIRRORS/arch/ <sub>[http://ftp.sh.cvut.cz/MIRRORS/arch/ http]</sub><br />
<br />
=== Estonia ===<br />
*ftp://ftp.estpak.ee/pub/archlinux/ <sub>[http://ftp.estpak.ee/pub/archlinux/ http]</sub><br />
<br />
=== Finland ===<br />
*ftp://ftp.sixnix.net/pub/archlinux/<br />
<br />
=== France ===<br />
*ftp://distrib-coffee.ipsl.jussieu.fr/pub/linux/archlinux/ <sub>[http://distrib-coffee.ipsl.jussieu.fr/pub/linux/archlinux/ http]</sub> <sub>[rsync://distrib-coffee.ipsl.jussieu.fr/pub/linux/archlinux/ rsync]</sub><br />
*ftp://mir1.archlinuxfr.org/archlinux <sub>[http://mir1.archlinuxfr.org/archlinux http]</sub> <sub>[rsync://mir1.archlinuxfr.org/archlinux rsync]</sub><br />
*ftp://mir2.archlinuxfr.org/archlinux <sub>[http://mir2.archlinuxfr.org/archlinux http]</sub> <sub>[rsync://mir2.archlinuxfr.org/archlinux rsync]</sub><br />
*http://mir.archlinux.fr/<br />
*ftp://ftp.free.fr/mirrors/ftp.archlinux.org/<br />
<br />
=== Germany ===<br />
*ftp://ftp.tu-chemnitz.de/pub/linux/sunsite.unc-mirror/distributions/archlinux/ <sub>[http://ftp.tu-chemnitz.de/pub/linux/sunsite.unc-mirror/distributions/archlinux/ http]</sub><br />
*ftp://ftp.hosteurope.de/mirror/ftp.archlinux.org/ <sub>[http://ftp.hosteurope.de/mirror/ftp.archlinux.org/ http]</sub><br />
*ftp://ftp.archlinuxppc.org/i686/<br />
<br />
=== Great Britain ===<br />
*http://www.mirrorservice.org/sites/ftp.archlinux.org/<br />
<br />
=== Greece ===<br />
*ftp://ftp.ntua.gr/pub/linux/archlinux/ <sub>[http://ftp.ntua.gr/pub/linux/archlinux/ http]</sub><br />
<br />
=== Hungary ===<br />
*ftp://ftp.mfa.kfki.hu/pub/mirrors/ftp.archlinux.org/<br />
<br />
=== Ireland ===<br />
*ftp://ftp.heanet.ie/mirrors/ftp.archlinux.org/ <sub>[http://ftp.heanet.ie/mirrors/ftp.archlinux.org/ http]</sub><br />
<br />
=== Israel ===<br />
*http://mirror.isoc.org.il/pub/archlinux/<br />
<br />
=== Italy ===<br />
*ftp://mi.mirror.garr.it/mirrors/archlinux/ <sub>[http://mi.mirror.garr.it/mirrors/archlinux/ http]</sub><br />
<br />
=== Netherlands ===<br />
*ftp://ftp.nluug.nl/pub/metalab/distributions/archlinux/ <sub>[http://ftp.nluug.nl/pub/metalab/distributions/archlinux/ http]</sub><br />
*ftp://ftp.surfnet.nl/pub/os/Linux/distr/archlinux/ <sub>[http://ftp.surfnet.nl/pub/os/Linux/distr/archlinux/ http]</sub><br />
<br />
=== Poland ===<br />
*ftp://ftp.icm.edu.pl/pub/Linux/sunsite/distributions/archlinux/ [http://ftp.icm.edu.pl/pub/Linux/sunsite/distributions/archlinux/ http]<br />
*ftp://mirror.icis.pcz.pl/archlinux/<br />
*ftp://ftp.piotrkosoft.net/pub/mirrors/ftp.archlinux.org/ [http://piotrkosoft.net/pub/mirrors/ftp.archlinux.org/ http]<br />
<br />
=== Portugal ===<br />
*ftp://cesium.di.uminho.pt/pub/archlinux/ <sub>[http://cesium.di.uminho.pt/pub/archlinux/ http]</sub><br />
<br />
=== Romania ===<br />
*ftp://ftp.iasi.roedu.net/mirrors/archlinux.org/ <sub>[http://ftp.iasi.roedu.net/mirrors/archlinux.org/ http]</sub><br />
<br />
=== Russia ===<br />
*ftp://archlinux.org.ru/pub/archlinux/ (rsync available)<br />
*ftp://mirror.yandex.ru/archlinux/ <sub>[http://mirror.yandex.ru/archlinux/ http]</sub> (rsync available)<br />
<br />
=== Sweden ===<br />
*ftp://ftp.ds.hj.se/pub/os/linux/archlinux/ <sub>[http://ftp.ds.hj.se/pub/os/linux/archlinux/ http]</sub><br />
*ftp://ftp.gigabit.nu/ <sub>[http://ftp.gigabit.nu/ http]</sub><br />
<br />
=== Switzerland ===<br />
*ftp://archlinux.puzzle.ch/ <sub>[http://archlinux.puzzle.ch/ http]</sub><br />
<br />
=== Turkey ===<br />
*http://server.elsistech.com/archlinux/<br />
<br />
=== Ukraine ===<br />
*ftp://hell.org.ua/archlinux/ (rsync available)<br />
*ftp://ftp.linux.kiev.ua/pub/Linux/ArchLinux/ <sub>[http://ftp.linux.kiev.ua/pub/Linux/ArchLinux/ http]</sub> (i686 only, no new isos)<br />
<br />
=== United States ===<br />
*ftp://ftp.archlinux.org/<br />
*ftp://ftp.nethat.com/pub/linux/archlinux/<br />
*ftp://locke.suu.edu/linux/dist/archlinux/<br />
*ftp://mirrors.unixheads.org/archlinux <sub>[http://mirrors.unixheads.org/archlinux http]</sub> (rsync available)<br />
*ftp://mirrors.easynews.com/linux/archlinux/ <sub>[http://mirrors.easynews.com/linux/archlinux/ http]</sub><br />
*ftp://ftp-linux.cc.gatech.edu/pub/linux/distributions/archlinux/ [http://ftp-linux.cc.gatech.edu/pub/linux/distributions/archlinux/ http]<br />
*ftp://mirror.cs.vt.edu/pub/ArchLinux/ <sub>[http://mirror.cs.vt.edu/pub/ArchLinux/ http]</sub><br />
*ftp://ibiblio.org/pub/linux/distributions/archlinux/ <sub>[http://distro.ibiblio.org/pub/linux/distributions/archlinux/ http]</sub><br />
*http://holmes.umflint.edu/archlinux/<br />
<br />
<br />
== Unofficial mirrors ==<br />
'''These mirrors are not listed in <code>/etc/pacman.d/*</code>.'''<br />
<br />
=== Global ===<br />
*http://prdownloads.sourceforge.net/archlinux/ ( Doesn't have recent ISO releases. Use it only if for some reason you want to use an older ISO. )<br />
<br />
=== Malaysia ===<br />
*http://oss.mmu.edu.my/distro/arch (ISOs only)<br />
<br />
=== Norway ===<br />
*ftp://jane.tihlde.org/pub/archlinux/ <sub>[http://jane.tihlde.org/pub/archlinux/ http] </sub> <sub> [rsync://jane.tihlde.org/pub/archlinux/ rsync] </sub><br />
<br />
=== Taiwan ===<br />
*ftp://cle.linux.org.tw/pub/ArchLinux/ (no ''testing'' and ''unstable'', no new isos)<br />
=== China ===<br />
http://mirrors.lcuc.org.cn/archlinux/<br />
<br><br />
http://mirror.lupaworld.com/archlinux/<br />
<br />
=== United States ===<br />
*ftp://ftp.osuosl.org/pub/archlinux/ <sub>[http://ftp.osuosl.org/pub/archlinux/ http]</sub> (i686 only - ''current'' and ''extra'') - outdated<br />
<br />
== IPv6-ready mirrors ==<br />
*niue.belnet.be (Belgium)<br />
*ftp.estpak.ee (Estonia)<br />
*patroklos.noc.ntua.gr (Greece)<br />
*ftp.heanet.ie (Ireland)<br />
*ftp.nluug.nl (Netherlands)<br />
*ftp.surfnet.nl (Netherlands)<br />
*ftp.sixnix.net/ftp6.sixnix.net (Finland)</div>Sixty-four-bithttps://wiki.archlinux.org/index.php?title=Mirrors&diff=35279Mirrors2008-01-20T08:23:25Z<p>Sixty-four-bit: /* Enabling your favorite mirror */</p>
<hr />
<div>[[Category:Package management (English)]]<br />
[[Category:HOWTOs (English)]]<br />
== Enabling your favorite mirror ==<br />
<br />
The default pacman configuration for ''core'' looks like this:<br />
<br />
[core]<br />
Include = /etc/pacman.d/core<br />
<br />
If you want to use the HostEurope mirror as your default mirror, just add it before the <tt>Include</tt> line:<br />
<br />
[core]<br />
Server = <nowiki>ftp://ftp.hosteurope.de/mirror/ftp.archlinux.org/core/os/i686</nowiki><br />
Include = /etc/pacman.d/core<br />
<br><br />
'''edit:''' The release of pacman 3.1 introduced the /etc/pacman.d/mirrorlist with the variable $repo, no need to maintain separate list for each repository.<br />
<br />
<pre><br />
[core]<br />
# Add your preferred servers here, they will be used first<br />
Include = /etc/pacman.d/mirrolist<br />
<br />
[extra]<br />
# Add your preferred servers here, they will be used first<br />
Include = /etc/pacman.d/mirrolist<br />
<br />
[community]<br />
# Add your preferred servers here, they will be used first<br />
Include = /etc/pacman.d/mirrolist<br />
</pre> <br />
<br />
Pacman will now try to connect to this mirror first. You can do the same for ''testing'', ''extra'', ''community'' and ''unstable''.<br />
<br />
'''Use the same mirror for all repositories. Otherwise packages may get installed that are incompatible to each other (like kernel26 from ''core'' and another (older) kernel module from ''extra'').'''<br />
<br />
== Mirror List ==<br />
<br />
This is a list of all known ArchLinux mirrors, that's more up to date than the [http://www.archlinux.org/download/ official download page] or the [http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/base/pacman/ files in <tt>/etc/pacman.d/</tt>]. If you know of a mirror that is not listed, please add it. Mirrors which are no longer updated or have been unavailable for a long time can be deleted.<br />
<br />
Here is a hint to check just how up-to-date your chosen mirror is:<br />
# pick a server and browse to "extra/os/"<br />
# load [http://www.archlinux.org/ ArchLinux.org] in another tab or window<br />
# compare the last-modified date of the "i686" directory on the mirror to the "Extra" date on the homepage, in the "Package Repositories" box to the right.<br />
<br><br />
Many sites also provide http service, but keep in mind that pacman relies on ftp to determine if a repository got updated. With http it fetches the repository database each time you run <tt>pacman -Sy</tt>, even if it didn't change since the last run.<br />
<br />
'''Attention: Do not add new mirrors to the list below. If you want your mirror to be added to official list - file a feature request. In the meantime add it to the "Unofficial mirrors" list at the end of this page.'''<br />
<br />
=== Australia ===<br />
*ftp://mirror.pacific.net.au/linux/archlinux/ <sub>[http://mirror.pacific.net.au/linux/archlinux/ http]</sub><br />
*ftp://mirror.aarnet.edu.au/pub/archlinux/ <sub>[http://mirror.aarnet.edu.au/pub/archlinux/ http]</sub><br />
<br />
=== Austria ===<br />
*ftp://gd.tuwien.ac.at/opsys/linux/archlinux/ <sub>[http://gd.tuwien.ac.at/opsys/linux/archlinux/ http]</sub><br />
*ftp://mirror.internode.on.net/pub/archlinux/ <sub>[http://mirror.internode.on.net/pub/archlinux/ http]</sub><br />
<br />
=== Belgium ===<br />
*ftp://ftp.belnet.be/mirror/archlinux.org/ <sub>[http://ftp.belnet.be/mirror/archlinux.org/ http]</sub><br />
<br />
=== Brazil ===<br />
*ftp://archlinux.c3sl.ufpr.br/archlinux/ <sub>[http://archlinux.c3sl.ufpr.br/ http]</sub><br />
<br />
=== Czech Republic ===<br />
*ftp://ftp.sh.cvut.cz/MIRRORS/arch/ <sub>[http://ftp.sh.cvut.cz/MIRRORS/arch/ http]</sub><br />
<br />
=== Estonia ===<br />
*ftp://ftp.estpak.ee/pub/archlinux/ <sub>[http://ftp.estpak.ee/pub/archlinux/ http]</sub><br />
<br />
=== Finland ===<br />
*ftp://ftp.sixnix.net/pub/archlinux/<br />
<br />
=== France ===<br />
*ftp://distrib-coffee.ipsl.jussieu.fr/pub/linux/archlinux/ <sub>[http://distrib-coffee.ipsl.jussieu.fr/pub/linux/archlinux/ http]</sub> <sub>[rsync://distrib-coffee.ipsl.jussieu.fr/pub/linux/archlinux/ rsync]</sub><br />
*ftp://mir1.archlinuxfr.org/archlinux <sub>[http://mir1.archlinuxfr.org/archlinux http]</sub> <sub>[rsync://mir1.archlinuxfr.org/archlinux rsync]</sub><br />
*ftp://mir2.archlinuxfr.org/archlinux <sub>[http://mir2.archlinuxfr.org/archlinux http]</sub> <sub>[rsync://mir2.archlinuxfr.org/archlinux rsync]</sub><br />
*http://mir.archlinux.fr/<br />
*ftp://ftp.free.fr/mirrors/ftp.archlinux.org/<br />
<br />
=== Germany ===<br />
*ftp://ftp.tu-chemnitz.de/pub/linux/sunsite.unc-mirror/distributions/archlinux/ <sub>[http://ftp.tu-chemnitz.de/pub/linux/sunsite.unc-mirror/distributions/archlinux/ http]</sub><br />
*ftp://ftp.hosteurope.de/mirror/ftp.archlinux.org/ <sub>[http://ftp.hosteurope.de/mirror/ftp.archlinux.org/ http]</sub><br />
*ftp://ftp.archlinuxppc.org/i686/<br />
<br />
=== Great Britain ===<br />
*http://www.mirrorservice.org/sites/ftp.archlinux.org/<br />
<br />
=== Greece ===<br />
*ftp://ftp.ntua.gr/pub/linux/archlinux/ <sub>[http://ftp.ntua.gr/pub/linux/archlinux/ http]</sub><br />
<br />
=== Hungary ===<br />
*ftp://ftp.mfa.kfki.hu/pub/mirrors/ftp.archlinux.org/<br />
<br />
=== Ireland ===<br />
*ftp://ftp.heanet.ie/mirrors/ftp.archlinux.org/ <sub>[http://ftp.heanet.ie/mirrors/ftp.archlinux.org/ http]</sub><br />
<br />
=== Israel ===<br />
*http://mirror.isoc.org.il/pub/archlinux/<br />
<br />
=== Italy ===<br />
*ftp://mi.mirror.garr.it/mirrors/archlinux/ <sub>[http://mi.mirror.garr.it/mirrors/archlinux/ http]</sub><br />
<br />
=== Netherlands ===<br />
*ftp://ftp.nluug.nl/pub/metalab/distributions/archlinux/ <sub>[http://ftp.nluug.nl/pub/metalab/distributions/archlinux/ http]</sub><br />
*ftp://ftp.surfnet.nl/pub/os/Linux/distr/archlinux/ <sub>[http://ftp.surfnet.nl/pub/os/Linux/distr/archlinux/ http]</sub><br />
<br />
=== Poland ===<br />
*ftp://ftp.icm.edu.pl/pub/Linux/sunsite/distributions/archlinux/ [http://ftp.icm.edu.pl/pub/Linux/sunsite/distributions/archlinux/ http]<br />
*ftp://mirror.icis.pcz.pl/archlinux/<br />
*ftp://ftp.piotrkosoft.net/pub/mirrors/ftp.archlinux.org/ [http://piotrkosoft.net/pub/mirrors/ftp.archlinux.org/ http]<br />
<br />
=== Portugal ===<br />
*ftp://cesium.di.uminho.pt/pub/archlinux/ <sub>[http://cesium.di.uminho.pt/pub/archlinux/ http]</sub><br />
<br />
=== Romania ===<br />
*ftp://ftp.iasi.roedu.net/mirrors/archlinux.org/ <sub>[http://ftp.iasi.roedu.net/mirrors/archlinux.org/ http]</sub><br />
<br />
=== Russia ===<br />
*ftp://archlinux.org.ru/pub/archlinux/ (rsync available)<br />
*ftp://mirror.yandex.ru/archlinux/ <sub>[http://mirror.yandex.ru/archlinux/ http]</sub> (rsync available)<br />
<br />
=== Sweden ===<br />
*ftp://ftp.ds.hj.se/pub/os/linux/archlinux/ <sub>[http://ftp.ds.hj.se/pub/os/linux/archlinux/ http]</sub><br />
*ftp://ftp.gigabit.nu/ <sub>[http://ftp.gigabit.nu/ http]</sub><br />
<br />
=== Switzerland ===<br />
*ftp://archlinux.puzzle.ch/ <sub>[http://archlinux.puzzle.ch/ http]</sub><br />
<br />
=== Turkey ===<br />
*http://server.elsistech.com/archlinux/<br />
<br />
=== Ukraine ===<br />
*ftp://hell.org.ua/archlinux/ (rsync available)<br />
*ftp://ftp.linux.kiev.ua/pub/Linux/ArchLinux/ <sub>[http://ftp.linux.kiev.ua/pub/Linux/ArchLinux/ http]</sub> (i686 only, no new isos)<br />
<br />
=== United States ===<br />
*ftp://ftp.archlinux.org/<br />
*ftp://ftp.nethat.com/pub/linux/archlinux/<br />
*ftp://locke.suu.edu/linux/dist/archlinux/<br />
*ftp://mirrors.unixheads.org/archlinux <sub>[http://mirrors.unixheads.org/archlinux http]</sub> (rsync available)<br />
*ftp://mirrors.easynews.com/linux/archlinux/ <sub>[http://mirrors.easynews.com/linux/archlinux/ http]</sub><br />
*ftp://ftp-linux.cc.gatech.edu/pub/linux/distributions/archlinux/ [http://ftp-linux.cc.gatech.edu/pub/linux/distributions/archlinux/ http]<br />
*ftp://mirror.cs.vt.edu/pub/ArchLinux/ <sub>[http://mirror.cs.vt.edu/pub/ArchLinux/ http]</sub><br />
*ftp://ibiblio.org/pub/linux/distributions/archlinux/ <sub>[http://distro.ibiblio.org/pub/linux/distributions/archlinux/ http]</sub><br />
*http://holmes.umflint.edu/archlinux/<br />
<br />
<br />
== Unofficial mirrors ==<br />
'''These mirrors are not listed in <code>/etc/pacman.d/*</code>.'''<br />
<br />
=== Global ===<br />
*http://prdownloads.sourceforge.net/archlinux/ ( Doesn't have recent ISO releases. Use it only if for some reason you want to use an older ISO. )<br />
<br />
=== Malaysia ===<br />
*http://oss.mmu.edu.my/distro/arch (ISOs only)<br />
<br />
=== Norway ===<br />
*ftp://jane.tihlde.org/pub/archlinux/ <sub>[http://jane.tihlde.org/pub/archlinux/ http] </sub> <sub> [rsync://jane.tihlde.org/pub/archlinux/ rsync] </sub><br />
<br />
=== Taiwan ===<br />
*ftp://cle.linux.org.tw/pub/ArchLinux/ (no ''testing'' and ''unstable'', no new isos)<br />
=== China ===<br />
http://mirrors.lcuc.org.cn/archlinux/<br />
<br><br />
http://mirror.lupaworld.com/archlinux/<br />
<br />
=== United States ===<br />
*ftp://ftp.osuosl.org/pub/archlinux/ <sub>[http://ftp.osuosl.org/pub/archlinux/ http]</sub> (i686 only - ''current'' and ''extra'') - outdated<br />
<br />
== IPv6-ready mirrors ==<br />
*niue.belnet.be (Belgium)<br />
*ftp.estpak.ee (Estonia)<br />
*patroklos.noc.ntua.gr (Greece)<br />
*ftp.heanet.ie (Ireland)<br />
*ftp.nluug.nl (Netherlands)<br />
*ftp.surfnet.nl (Netherlands)<br />
*ftp.sixnix.net/ftp6.sixnix.net (Finland)</div>Sixty-four-bithttps://wiki.archlinux.org/index.php?title=Pacman&diff=35278Pacman2008-01-20T08:18:44Z<p>Sixty-four-bit: /* Repositories */</p>
<hr />
<div>[[Category:Package management (English)]]<br />
[[Category:Utilities (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
{{i18n_links_start}}<br />
{{i18n_entry|Česky|:Pacman (Česky)}}<br />
{{i18n_entry|Dansk|:Pacman_(Dansk)}}<br />
{{i18n_entry|Deutsch|:Pacman (Deutsch)}}<br />
{{i18n_entry|English|:Pacman}}<br />
{{i18n_entry|Español|:Pacman (Español)}}<br />
{{i18n_entry|Français|:Pacman (Français)}}<br />
{{i18n_entry|Italiano|:Pacman (Italiano)}}<br />
{{i18n_entry|Nederlands|:Pacman (Nederlands)}}<br />
{{i18n_entry|Polski|:Pacman (Polski)}}<br />
{{i18n_entry|Português de Portugal|:Pacman (Portugues)}}<br />
{{i18n_entry|Romanian|:Pacman (română)}}<br />
{{i18n_entry|Русский|:Pacman (Русский)}}<br />
{{i18n_entry|简体中文|:Pacman (简体中文)}}<br />
{{i18n_entry|한국어|:Pacman (한국어)}}<br />
{{i18n_links_end}}<br />
<br />
==Overview==<br />
The '''[http://archlinux.org/pacman/ Pacman]''' package manager is one of the great highlights of Arch Linux. It combines a simple binary package format with an easy-to-use build system (see [[makepkg]] and [[ABS]]). '''Pacman''' makes it possible to easily manage packages, whether they be from the official Arch repositories or the user's own builds.<br />
<br />
'''Pacman''' can keep a system up to date by synchronizing package lists with the master server. This server/client model also allows you to download/install packages with a simple command, complete with all required dependencies (similar to Debian's apt-get).<br />
<br />
==Usage==<br />
<br />
To really learn what pacman can do, read [http://archlinux.org/pacman/pacman.8.html man pacman]. The below is just a small sample of operations that can be performed.<br />
<br />
===Installing and Removing Packages===<br />
Before installing and upgrading packages, it is a good idea to synchronize the local package database with the remote repositories.<br />
<br />
pacman -Sy<br />
or<br />
pacman --sync --refresh<br />
<br />
To install or upgrade a single package or list of packages (including dependencies), issue the following command:<br />
<br />
pacman -S package_name1 package_name2<br />
<br />
Sometimes there are more versions of a package in different repositories (e.g. extra and testing). You can specify which one to install:<br />
<br />
pacman -S extra/package_name<br />
pacman -S testing/package_name<br />
<br />
You can also refresh the package database before installing a package in one command:<br />
<br />
pacman -Sy package_name<br />
<br />
To remove a single package, leaving all of its dependencies installed:<br />
<br />
pacman -R package_name<br />
<br />
To remove all of the packages dependencies which aren't used by any other installed package:<br />
<br />
pacman -Rs package_name<br />
<br />
To remove a package without checking dependencies:<br />
<br />
pacman -Rd package_name<br />
<br />
===Upgrading the System===<br />
<br />
'''Pacman''' can update all packages on the system with just one command. This could take quite a while depending on how up-to-date your system is.<br />
<br />
pacman -Su<br />
<br />
However, the best option is to synchronize the repository databases AND update your system in one go with the following:<br />
<br />
pacman -Syu<br />
<br />
===Querying the Package Database===<br />
<br />
'''Pacman''' can search the package database for a list of packages, you can enter part of the package name to search for all packages matching the string:<br />
<br />
pacman -Ss package<br />
<br />
To search installed packages only:<br />
<br />
pacman -Qs package<br />
<br />
Once you know the name of the package you are looking for, you can display some information on the package. Note that ''query info'' (-Qi) will show more info than ''sync info'' (-Si), as long as the package is installed.<br />
<br />
pacman -Si package <br />
pacman -Qi package<br />
<br />
For a list of files contained in a package:<br />
<br />
pacman -Ql package<br />
<br />
For a list of files formally installed as dependencies, but no longer in use by any currently installed packages:<br />
<br />
pacman -Qdt<br />
<br />
For a list of files explicitly installed, but not required by any other package:<br />
<br />
pacman -Qet<br />
<br />
You can also query what package a file on your system belongs to.<br />
<br />
pacman -Qo /path/to/file<br />
<br />
===Other Usage===<br />
<br />
'''Pacman''' is quite an extensive package management tool, here is just a brief collection of other features.<br />
<br />
* Download a package without installing it:<br />
pacman -Sw package_name<br />
<br />
* Install a local package (not from a repository):<br />
pacman -U /path/to/package/package_name-version.pkg.tar.gz<br />
<br />
* Fully clean the package cache (/var/cache/pacman/pkg):<br />
pacman -Scc<br />
<br />
* Reinstall a package (that can't be removed first because of dependencies problems):<br />
pacman -Sf package_name<br />
<br />
For a more detailed list of switches please refer to <code>pacman --help</code> or <code>man pacman</code>.<br />
<br />
==Configuration==<br />
Pacman configuration is located in <code>/etc/pacman.conf</code>. In depth information about the configuration file can be found in <code>man pacman.conf</code>.<br />
<br />
===General options===<br />
General options are in [options] section. Read the man page or look in the default pacman.conf for information on what can be done here.<br />
<br />
===Repositories===<br />
In this section you define which repositories to use, as referred to in /etc/pacman.conf, and then listed in /etc/pacman.d/. They can be defined directly there or you can include them from another file. <strike>The files found in this directory include, community, core, extra, release, testing and unstable. It is important to edit each one to include the repositories you require.</strike>'''(depreciated in pacman 3.1, check edit)''' The following is an example for the official repositories which have a lot of [[mirrors]]. Avoid using ftp.archlinux.org as it is [http://www.archlinux.org/news/302/ throttled].<br />
<br />
<pre><br />
[repository-name]<br />
Server = ftp://server.net/repo<br />
</pre><br />
<br />
<pre><br />
[core]<br />
# Add your preferred servers here, they will be used first<br />
Include = /etc/pacman.d/core<br />
</pre><br />
<br><br />
'''edit:''' starting with pacman 3.1, all repositories will use the same /etc/pacman.d/mirrorlist which contains a variable '$repo'. This just cleans up the mirrorlist and removes some of the 'bloat'. No need to maintain more then mirrorlist. K.I.S.S. method.<br />
<pre><br />
[core]<br />
# Add your preferred servers here, they will be used first<br />
Include = /etc/pacman.d/mirrolist<br />
<br />
[extra]<br />
# Add your preferred servers here, they will be used first<br />
Include = /etc/pacman.d/mirrolist<br />
<br />
[community]<br />
# Add your preferred servers here, they will be used first<br />
Include = /etc/pacman.d/mirrolist<br />
</pre><br />
<br />
'''n.b.''' Care should be taken when using '''testing''' and '''unstable''' repositories<br />
<br />
===Errors===<br />
<br />
If you receive the following error<br />
'''not found in sync db'''<br />
this likely due to the package not being located because the repositry has not been set correctly.<br />
<br />
==Related links==<br />
<br />
'''man-pages''':<br />
*[http://www.archlinux.org/pacman/pacman.8.html man pacman]<br />
*[http://www.archlinux.org/pacman/PKGBUILD.5.html man PKGBUILD]<br />
*[http://www.archlinux.org/pacman/libalpm.3.html man libalpm]<br />
*[http://www.archlinux.org/pacman/pacman.conf.5.html man pacman.conf]<br />
*[http://www.archlinux.org/pacman/makepkg.8.html man makepkg]<br />
*[http://www.archlinux.org/pacman/makepkg.conf.5.html man makepkg.conf]<br />
*[http://www.archlinux.org/pacman/repo-add.8.html man repo-add]<br />
<br />
'''other wiki-entries''':<br />
<br />
[[Improve Pacman Performance]]<br><br />
[[Colored Pacman output]]<br><br />
[[Downgrade packages]]<br><br />
[http://www.archlinux.org/pacman/pacman.conf.5.html Editing pacman.conf]<br><br />
[[Redownloading all installed packages]]<br><br />
[[Server_configuration|Server configuration in pacman.conf]]<br><br />
[[ArchLinux User-community Repository (AUR)]]<br><br />
[[Local repository HOW-TO]]<br><br />
[[Custom local repository with ABS and gensync]]<br><br />
[[Howto Upgrade via Home Network]] (Network Shared Pacman Cache)<br><br />
[[rucksack]]<br><br />
[[Pacman GUI Frontends]]<br><br />
[[Pacman_Aliases|Pacman Aliases (for bash)]]</div>Sixty-four-bithttps://wiki.archlinux.org/index.php?title=Pacman&diff=35277Pacman2008-01-20T08:13:56Z<p>Sixty-four-bit: /* Repositories */</p>
<hr />
<div>[[Category:Package management (English)]]<br />
[[Category:Utilities (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
{{i18n_links_start}}<br />
{{i18n_entry|Česky|:Pacman (Česky)}}<br />
{{i18n_entry|Dansk|:Pacman_(Dansk)}}<br />
{{i18n_entry|Deutsch|:Pacman (Deutsch)}}<br />
{{i18n_entry|English|:Pacman}}<br />
{{i18n_entry|Español|:Pacman (Español)}}<br />
{{i18n_entry|Français|:Pacman (Français)}}<br />
{{i18n_entry|Italiano|:Pacman (Italiano)}}<br />
{{i18n_entry|Nederlands|:Pacman (Nederlands)}}<br />
{{i18n_entry|Polski|:Pacman (Polski)}}<br />
{{i18n_entry|Português de Portugal|:Pacman (Portugues)}}<br />
{{i18n_entry|Romanian|:Pacman (română)}}<br />
{{i18n_entry|Русский|:Pacman (Русский)}}<br />
{{i18n_entry|简体中文|:Pacman (简体中文)}}<br />
{{i18n_entry|한국어|:Pacman (한국어)}}<br />
{{i18n_links_end}}<br />
<br />
==Overview==<br />
The '''[http://archlinux.org/pacman/ Pacman]''' package manager is one of the great highlights of Arch Linux. It combines a simple binary package format with an easy-to-use build system (see [[makepkg]] and [[ABS]]). '''Pacman''' makes it possible to easily manage packages, whether they be from the official Arch repositories or the user's own builds.<br />
<br />
'''Pacman''' can keep a system up to date by synchronizing package lists with the master server. This server/client model also allows you to download/install packages with a simple command, complete with all required dependencies (similar to Debian's apt-get).<br />
<br />
==Usage==<br />
<br />
To really learn what pacman can do, read [http://archlinux.org/pacman/pacman.8.html man pacman]. The below is just a small sample of operations that can be performed.<br />
<br />
===Installing and Removing Packages===<br />
Before installing and upgrading packages, it is a good idea to synchronize the local package database with the remote repositories.<br />
<br />
pacman -Sy<br />
or<br />
pacman --sync --refresh<br />
<br />
To install or upgrade a single package or list of packages (including dependencies), issue the following command:<br />
<br />
pacman -S package_name1 package_name2<br />
<br />
Sometimes there are more versions of a package in different repositories (e.g. extra and testing). You can specify which one to install:<br />
<br />
pacman -S extra/package_name<br />
pacman -S testing/package_name<br />
<br />
You can also refresh the package database before installing a package in one command:<br />
<br />
pacman -Sy package_name<br />
<br />
To remove a single package, leaving all of its dependencies installed:<br />
<br />
pacman -R package_name<br />
<br />
To remove all of the packages dependencies which aren't used by any other installed package:<br />
<br />
pacman -Rs package_name<br />
<br />
To remove a package without checking dependencies:<br />
<br />
pacman -Rd package_name<br />
<br />
===Upgrading the System===<br />
<br />
'''Pacman''' can update all packages on the system with just one command. This could take quite a while depending on how up-to-date your system is.<br />
<br />
pacman -Su<br />
<br />
However, the best option is to synchronize the repository databases AND update your system in one go with the following:<br />
<br />
pacman -Syu<br />
<br />
===Querying the Package Database===<br />
<br />
'''Pacman''' can search the package database for a list of packages, you can enter part of the package name to search for all packages matching the string:<br />
<br />
pacman -Ss package<br />
<br />
To search installed packages only:<br />
<br />
pacman -Qs package<br />
<br />
Once you know the name of the package you are looking for, you can display some information on the package. Note that ''query info'' (-Qi) will show more info than ''sync info'' (-Si), as long as the package is installed.<br />
<br />
pacman -Si package <br />
pacman -Qi package<br />
<br />
For a list of files contained in a package:<br />
<br />
pacman -Ql package<br />
<br />
For a list of files formally installed as dependencies, but no longer in use by any currently installed packages:<br />
<br />
pacman -Qdt<br />
<br />
For a list of files explicitly installed, but not required by any other package:<br />
<br />
pacman -Qet<br />
<br />
You can also query what package a file on your system belongs to.<br />
<br />
pacman -Qo /path/to/file<br />
<br />
===Other Usage===<br />
<br />
'''Pacman''' is quite an extensive package management tool, here is just a brief collection of other features.<br />
<br />
* Download a package without installing it:<br />
pacman -Sw package_name<br />
<br />
* Install a local package (not from a repository):<br />
pacman -U /path/to/package/package_name-version.pkg.tar.gz<br />
<br />
* Fully clean the package cache (/var/cache/pacman/pkg):<br />
pacman -Scc<br />
<br />
* Reinstall a package (that can't be removed first because of dependencies problems):<br />
pacman -Sf package_name<br />
<br />
For a more detailed list of switches please refer to <code>pacman --help</code> or <code>man pacman</code>.<br />
<br />
==Configuration==<br />
Pacman configuration is located in <code>/etc/pacman.conf</code>. In depth information about the configuration file can be found in <code>man pacman.conf</code>.<br />
<br />
===General options===<br />
General options are in [options] section. Read the man page or look in the default pacman.conf for information on what can be done here.<br />
<br />
===Repositories===<br />
In this section you define which repositories to use, as referred to in /etc/pacman.conf, and then listed in /etc/pacman.d/. They can be defined directly there or you can include them from another file. <strike>The files found in this directory include, community, core, extra, release, testing and unstable. It is important to edit each one to include the repositories you require.</strike>'''(depreciated in pacman 3.1, check edit)''' The following is an example for the official repositories which have a lot of [[mirrors]]. Avoid using ftp.archlinux.org as it is [http://www.archlinux.org/news/302/ throttled].<br />
<br />
<pre><br />
[repository-name]<br />
Server = ftp://server.net/repo<br />
</pre><br />
<br />
<pre><br />
[core]<br />
# Add your preferred servers here, they will be used first<br />
Include = /etc/pacman.d/core<br />
</pre><br />
<br><br />
'''edit:''' starting with pacman 3.1, all repositories will use the same /etc/pacman.d/mirrorlist which contains a variable '$repo', selecting which repository is needed is done automatically now.<br />
<br />
<pre><br />
[core]<br />
# Add your preferred servers here, they will be used first<br />
Include = /etc/pacman.d/mirrolist<br />
<br />
[extra]<br />
# Add your preferred servers here, they will be used first<br />
Include = /etc/pacman.d/mirrolist<br />
<br />
[community]<br />
# Add your preferred servers here, they will be used first<br />
Include = /etc/pacman.d/mirrolist<br />
</pre><br />
<br />
'''n.b.''' Care should be taken when using '''testing''' and '''unstable''' repositories<br />
<br />
===Errors===<br />
<br />
If you receive the following error<br />
'''not found in sync db'''<br />
this likely due to the package not being located because the repositry has not been set correctly.<br />
<br />
==Related links==<br />
<br />
'''man-pages''':<br />
*[http://www.archlinux.org/pacman/pacman.8.html man pacman]<br />
*[http://www.archlinux.org/pacman/PKGBUILD.5.html man PKGBUILD]<br />
*[http://www.archlinux.org/pacman/libalpm.3.html man libalpm]<br />
*[http://www.archlinux.org/pacman/pacman.conf.5.html man pacman.conf]<br />
*[http://www.archlinux.org/pacman/makepkg.8.html man makepkg]<br />
*[http://www.archlinux.org/pacman/makepkg.conf.5.html man makepkg.conf]<br />
*[http://www.archlinux.org/pacman/repo-add.8.html man repo-add]<br />
<br />
'''other wiki-entries''':<br />
<br />
[[Improve Pacman Performance]]<br><br />
[[Colored Pacman output]]<br><br />
[[Downgrade packages]]<br><br />
[http://www.archlinux.org/pacman/pacman.conf.5.html Editing pacman.conf]<br><br />
[[Redownloading all installed packages]]<br><br />
[[Server_configuration|Server configuration in pacman.conf]]<br><br />
[[ArchLinux User-community Repository (AUR)]]<br><br />
[[Local repository HOW-TO]]<br><br />
[[Custom local repository with ABS and gensync]]<br><br />
[[Howto Upgrade via Home Network]] (Network Shared Pacman Cache)<br><br />
[[rucksack]]<br><br />
[[Pacman GUI Frontends]]<br><br />
[[Pacman_Aliases|Pacman Aliases (for bash)]]</div>Sixty-four-bithttps://wiki.archlinux.org/index.php?title=Arch_Linux_Stable&diff=35126Arch Linux Stable2008-01-16T17:12:33Z<p>Sixty-four-bit: /* Communication */</p>
<hr />
<div>==Arch Linux Stable Branch/Snapshot==<br />
<br />
In reference to the discussion in [http://bbs.archlinux.org/viewtopic.php?id=41764&p=1 this] forum thread, the proposition has been put forth, initially by '''nagoola''', to provide a stable branch or snapshot of the Arch Linux distribution. <br />
<br />
===GOAL===<br />
<br />
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.<br />
<br />
===Concept===<br />
<br />
Why a stable branch? A general consensus has been formed, of the opinion that such a project will be advantageous in several ways:<br />
<br />
1. For the stability of workstations/production machines:<br />
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''."<br />
<br />
2. Desktops/Personal machines: <br />
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.<br />
<br />
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. <br />
<br />
===Definition===<br />
<br />
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.<br />
<br />
===Requirements===<br />
<br />
'''Communication is a must between all involved.'''<br />
<br />
<br />
1. Project Leader - Delegate tasks and project direction.<br />
<br />
2. Packagers - Choosing and handling packages to add to the snapshot repository.<br />
<br />
3. Testers - Testing the stability of packages, logistics, and assistance.<br />
<br />
4. Repository - Will require a server.<br />
<br />
5. (Possibly) Scripting - submit a prototype script below, which can tweak the client (user) pacman.conf to ignorepkg= ''unstablepkg''<br />
<br />
===Communication===<br />
<br />
'''IRC''' - [http://irc.freenode.net irc.freenode.net] #archlinux-stable<br><br />
'''Mailing list''' - [mailto:archlinux-stable-request@freelists.org archlinux-stable-request@freelists.org] Send e-mail with the subject 'subscribe'<br><br />
<br />
===Project Volunteers===<br />
<br />
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.<br />
<br />
Currently, the project has recruited these members:<br />
<br />
* nagoola - Project Management tasks / Communication. Also programming or package maintenance.<br />
* Nihathrael - Project Management / Programming / Documentation / Homepage / Package maintenance<br />
* rxKaffee - Programming / Provides testing server / Package maintenance<br />
* ibendiben - Coming soon, yet to decide<br />
* Misfit138 - Wrote this page-I am above average with English. Below average at GNU/Linux.<br />
* Basn - Packager<br />
* sixty-four-bit - Packager<br />
* AndyRTR - technical adviser, moderation / coordination if wanted/needed, maybe some packaging for core stuff<br />
* my64<br />
* hussam<br />
<br />
(Please add/remove your name as appropriate and state briefly what you are qualified to offer the project.)<br />
<br />
===Project Status===<br />
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.<br><br />
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.<br />
<br />
===Methodology===<br />
<br />
section has been modified<br />
[[User:Nihathrael|Nihathrael]] 10:07 am, 15 January 2008 (EST)<br />
[[User:sixty-four-bit|sixty-four-bit]] 10:03 pm, 15 January 2008 (EST): satisfy concerns from andyrtr and ise<br />
Please advise on this issue.<br />
<br />
After some discussion on IRC the following approach has been formed:<br />
<br />
# 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)] <br><br><br />
# 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.<br><br><br />
#* Packages will be updated if for one of the following reasons:<br><br />
#*# A major package update is released upstream, which has proven to be stable and bug/security fixed over time<br><br />
#*#* In case an upgrade needs human interaction the package is updated with the help of the project's own <b>"secure-install-script"</b>, which will be explained later, in section below.<br><br><br />
#*# A minor package update is released upstream that provides a bug/security fix and is considered stable.<br><br><br />
#*# 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.<br><br />
<br><br><br />
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...<br><br> <br />
<b>Special programs needed:</b> These are just the early design goals, please join the discussion IRC - irc.freenode.net #archlinux-stable<br> <br />
# 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)<br><br><br />
# 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.<br>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)<br><br><br />
# 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)<br />
<br />
==Sandbox==<br />
<br />
Crouse's Notes:<br />
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).<br />
<br />
Here is part of my auto-update script I use for my machines.... nothing earth shattering.<br />
I use a cronjob that does 2 things... <br />
<br />
1st downloads a pacman.conf file. Anything that I don't want updated is not updated.<br />
Using the pacman.conf file, an assortment of options present themselves to help keep a system "stable".<br />
Examples:<br />
<br />
IgnorePkg = kernel26<br />
NoUpgrade = etc/lilo.conf boot/grub/menu.lst<br />
HoldPkg = pacman glibc<br />
<br />
<br />
Again, nothing earth shattering, but it does allow me to keep packages that are breaking things, out of the system until proven trustworthy.<br />
<br />
2nd runs an automatic update script (because I'm lazy and don't want to update a dozen plus machines all the time.<br />
Here is the code for that part:<br />
<br />
#Pacman update and logging starts here<br />
echo " " 2>&1 >> /var/log/client.UPDATELOG<br />
echo "#############################################################" 2>&1 >> /var/log/client.UPDATELOG<br />
echo -ne "ARCH CLIENT UPDATE: " 2>&1 >> /var/log/client.UPDATELOG; echo `date +"%D %r"` 2>&1 >> /var/log/client.UPDATELOG<br />
echo "#############################################################" 2>&1 >> /var/log/client.UPDATELOG<br />
# Uncomment here if you want pacman to automatically update this machine<br />
pacman -Syu --noprogressbar --noconfirm 2>&1 >> /var/log/client.UPDATELOG<br />
# If you use lilo, remember to also uncomment the next line<br />
# /sbin/lilo 2>&1 >> /var/log/client.UPDATELOG<br />
<br />
Sorry if this is a bit messy....... feel free to "clean-up" my wiki mess here at the end :)<br />
<br />
<br />
<br />
==Old Entries==<br />
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.<br />
<br />
===Methodology Possibilities===<br />
<br />
Several different methods of achieving the project goal have been proposed-<br />
<br />
They include:<br />
<br />
1. Loosely basing the stable branch on Slackware packaging- expand to clarify, discuss.<br />
a. Follow Slackware-Current<br />
1. Kernel 2.6.23.12<br />
b. Follow Slackware-Stable<br />
1. Kernel 2.6.21<br />
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.<br />
http://distrowatch.com/table.php?distribution=rubix<br />
Review: http://www.tuxmachines.org/node/4699<br />
<br />
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. <br />
<br />
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.<br />
<br />
4. Loosely basing the stable branch on the Frugalware methodology. (Expand to clarify.)<br />
<br />
5. No stable "release" per se, but rather, stable packages.<br />
<br />
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.<br />
''Submit a script here by pasting it below.''<br />
<br />
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.<br />
<br />
===Release-Cycle Ideas===<br />
<br />
<br />
There could be a [core-stable] repository. This repository contains all the packages the normal [core] repo contains. <br><br />
There are 3 possibilities/ideas:<br><br />
<br />
====Version A====<br />
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.<br><br />
Benefits:<br><br />
* Pretty much rock-solid core repository that is very unlikely to break during the 3 months it is used.<br><br />
Disadvantages:<br><br />
* A lot of work is required to back-port security fixes to the rather old packages.<br><br />
* Probably a huge update is required from one release to another.<br><br />
* No upstream improvements/new features are introduced during one release.<br><br />
<br />
====Version B====<br />
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.<br><br />
Benefits:<br><br />
* Stable core repository with very few/none update problems.<br><br />
* 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.<br><br />
* Almost no need to back-port security fixes(only for "problem-packages")<br><br />
Disadvantages:<br><br />
* Higher risk of making the stable repository unstable, by updating packages that cause unknown problems.<br><br />
* 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].<br />
====Version C====<br />
''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.''<br><br />
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). <br />
This is rather advanced and should not be the first thing to try.<br><br />
<br />
All of these are only ideas and need detailed thoughts. So feel free to add/change anything you like.<br />
<br />
<br />
<br />
'''Please feel free to add to or otherwise modify this project page and join the discussion at irc.freenode.net #archlinux-stable'''</div>Sixty-four-bithttps://wiki.archlinux.org/index.php?title=Arch_Linux_Stable&diff=35125Arch Linux Stable2008-01-16T17:12:13Z<p>Sixty-four-bit: /* Communication */</p>
<hr />
<div>==Arch Linux Stable Branch/Snapshot==<br />
<br />
In reference to the discussion in [http://bbs.archlinux.org/viewtopic.php?id=41764&p=1 this] forum thread, the proposition has been put forth, initially by '''nagoola''', to provide a stable branch or snapshot of the Arch Linux distribution. <br />
<br />
===GOAL===<br />
<br />
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.<br />
<br />
===Concept===<br />
<br />
Why a stable branch? A general consensus has been formed, of the opinion that such a project will be advantageous in several ways:<br />
<br />
1. For the stability of workstations/production machines:<br />
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''."<br />
<br />
2. Desktops/Personal machines: <br />
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.<br />
<br />
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. <br />
<br />
===Definition===<br />
<br />
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.<br />
<br />
===Requirements===<br />
<br />
'''Communication is a must between all involved.'''<br />
<br />
<br />
1. Project Leader - Delegate tasks and project direction.<br />
<br />
2. Packagers - Choosing and handling packages to add to the snapshot repository.<br />
<br />
3. Testers - Testing the stability of packages, logistics, and assistance.<br />
<br />
4. Repository - Will require a server.<br />
<br />
5. (Possibly) Scripting - submit a prototype script below, which can tweak the client (user) pacman.conf to ignorepkg= ''unstablepkg''<br />
<br />
===Communication===<br />
<br />
'''IRC''' - [http://irc.freenode.net irc.freenode.net] #archlinux-stable<br><br />
'''Mailing list''' - [mailto:archlinux-stable-request@freelists.org archlinux-stable-request@freelists.org] Send e-mail with the subject 'signup'<br><br />
<br />
===Project Volunteers===<br />
<br />
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.<br />
<br />
Currently, the project has recruited these members:<br />
<br />
* nagoola - Project Management tasks / Communication. Also programming or package maintenance.<br />
* Nihathrael - Project Management / Programming / Documentation / Homepage / Package maintenance<br />
* rxKaffee - Programming / Provides testing server / Package maintenance<br />
* ibendiben - Coming soon, yet to decide<br />
* Misfit138 - Wrote this page-I am above average with English. Below average at GNU/Linux.<br />
* Basn - Packager<br />
* sixty-four-bit - Packager<br />
* AndyRTR - technical adviser, moderation / coordination if wanted/needed, maybe some packaging for core stuff<br />
* my64<br />
* hussam<br />
<br />
(Please add/remove your name as appropriate and state briefly what you are qualified to offer the project.)<br />
<br />
===Project Status===<br />
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.<br><br />
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.<br />
<br />
===Methodology===<br />
<br />
section has been modified<br />
[[User:Nihathrael|Nihathrael]] 10:07 am, 15 January 2008 (EST)<br />
[[User:sixty-four-bit|sixty-four-bit]] 10:03 pm, 15 January 2008 (EST): satisfy concerns from andyrtr and ise<br />
Please advise on this issue.<br />
<br />
After some discussion on IRC the following approach has been formed:<br />
<br />
# 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)] <br><br><br />
# 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.<br><br><br />
#* Packages will be updated if for one of the following reasons:<br><br />
#*# A major package update is released upstream, which has proven to be stable and bug/security fixed over time<br><br />
#*#* In case an upgrade needs human interaction the package is updated with the help of the project's own <b>"secure-install-script"</b>, which will be explained later, in section below.<br><br><br />
#*# A minor package update is released upstream that provides a bug/security fix and is considered stable.<br><br><br />
#*# 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.<br><br />
<br><br><br />
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...<br><br> <br />
<b>Special programs needed:</b> These are just the early design goals, please join the discussion IRC - irc.freenode.net #archlinux-stable<br> <br />
# 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)<br><br><br />
# 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.<br>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)<br><br><br />
# 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)<br />
<br />
==Sandbox==<br />
<br />
Crouse's Notes:<br />
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).<br />
<br />
Here is part of my auto-update script I use for my machines.... nothing earth shattering.<br />
I use a cronjob that does 2 things... <br />
<br />
1st downloads a pacman.conf file. Anything that I don't want updated is not updated.<br />
Using the pacman.conf file, an assortment of options present themselves to help keep a system "stable".<br />
Examples:<br />
<br />
IgnorePkg = kernel26<br />
NoUpgrade = etc/lilo.conf boot/grub/menu.lst<br />
HoldPkg = pacman glibc<br />
<br />
<br />
Again, nothing earth shattering, but it does allow me to keep packages that are breaking things, out of the system until proven trustworthy.<br />
<br />
2nd runs an automatic update script (because I'm lazy and don't want to update a dozen plus machines all the time.<br />
Here is the code for that part:<br />
<br />
#Pacman update and logging starts here<br />
echo " " 2>&1 >> /var/log/client.UPDATELOG<br />
echo "#############################################################" 2>&1 >> /var/log/client.UPDATELOG<br />
echo -ne "ARCH CLIENT UPDATE: " 2>&1 >> /var/log/client.UPDATELOG; echo `date +"%D %r"` 2>&1 >> /var/log/client.UPDATELOG<br />
echo "#############################################################" 2>&1 >> /var/log/client.UPDATELOG<br />
# Uncomment here if you want pacman to automatically update this machine<br />
pacman -Syu --noprogressbar --noconfirm 2>&1 >> /var/log/client.UPDATELOG<br />
# If you use lilo, remember to also uncomment the next line<br />
# /sbin/lilo 2>&1 >> /var/log/client.UPDATELOG<br />
<br />
Sorry if this is a bit messy....... feel free to "clean-up" my wiki mess here at the end :)<br />
<br />
<br />
<br />
==Old Entries==<br />
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.<br />
<br />
===Methodology Possibilities===<br />
<br />
Several different methods of achieving the project goal have been proposed-<br />
<br />
They include:<br />
<br />
1. Loosely basing the stable branch on Slackware packaging- expand to clarify, discuss.<br />
a. Follow Slackware-Current<br />
1. Kernel 2.6.23.12<br />
b. Follow Slackware-Stable<br />
1. Kernel 2.6.21<br />
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.<br />
http://distrowatch.com/table.php?distribution=rubix<br />
Review: http://www.tuxmachines.org/node/4699<br />
<br />
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. <br />
<br />
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.<br />
<br />
4. Loosely basing the stable branch on the Frugalware methodology. (Expand to clarify.)<br />
<br />
5. No stable "release" per se, but rather, stable packages.<br />
<br />
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.<br />
''Submit a script here by pasting it below.''<br />
<br />
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.<br />
<br />
===Release-Cycle Ideas===<br />
<br />
<br />
There could be a [core-stable] repository. This repository contains all the packages the normal [core] repo contains. <br><br />
There are 3 possibilities/ideas:<br><br />
<br />
====Version A====<br />
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.<br><br />
Benefits:<br><br />
* Pretty much rock-solid core repository that is very unlikely to break during the 3 months it is used.<br><br />
Disadvantages:<br><br />
* A lot of work is required to back-port security fixes to the rather old packages.<br><br />
* Probably a huge update is required from one release to another.<br><br />
* No upstream improvements/new features are introduced during one release.<br><br />
<br />
====Version B====<br />
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.<br><br />
Benefits:<br><br />
* Stable core repository with very few/none update problems.<br><br />
* 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.<br><br />
* Almost no need to back-port security fixes(only for "problem-packages")<br><br />
Disadvantages:<br><br />
* Higher risk of making the stable repository unstable, by updating packages that cause unknown problems.<br><br />
* 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].<br />
====Version C====<br />
''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.''<br><br />
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). <br />
This is rather advanced and should not be the first thing to try.<br><br />
<br />
All of these are only ideas and need detailed thoughts. So feel free to add/change anything you like.<br />
<br />
<br />
<br />
'''Please feel free to add to or otherwise modify this project page and join the discussion at irc.freenode.net #archlinux-stable'''</div>Sixty-four-bithttps://wiki.archlinux.org/index.php?title=Arch_Linux_Stable&diff=35123Arch Linux Stable2008-01-16T14:20:11Z<p>Sixty-four-bit: /* Communication */</p>
<hr />
<div>==Arch Linux Stable Branch/Snapshot==<br />
<br />
In reference to the discussion in [http://bbs.archlinux.org/viewtopic.php?id=41764&p=1 this] forum thread, the proposition has been put forth, initially by '''nagoola''', to provide a stable branch or snapshot of the Arch Linux distribution. <br />
<br />
===GOAL===<br />
<br />
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.<br />
<br />
===Concept===<br />
<br />
Why a stable branch? A general consensus has been formed, of the opinion that such a project will be advantageous in several ways:<br />
<br />
1. For the stability of workstations/production machines:<br />
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''."<br />
<br />
2. Desktops/Personal machines: <br />
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.<br />
<br />
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. <br />
<br />
===Definition===<br />
<br />
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.<br />
<br />
===Requirements===<br />
<br />
'''Communication is a must between all involved.'''<br />
<br />
<br />
1. Project Leader - Delegate tasks and project direction.<br />
<br />
2. Packagers - Choosing and handling packages to add to the snapshot repository.<br />
<br />
3. Testers - Testing the stability of packages, logistics, and assistance.<br />
<br />
4. Repository - Will require a server.<br />
<br />
5. (Possibly) Scripting - submit a prototype script below, which can tweak the client (user) pacman.conf to ignorepkg= ''unstablepkg''<br />
<br />
===Communication===<br />
<br />
'''IRC''' - [http://irc.freenode.net irc.freenode.net] #archlinux-stable<br><br />
'''Mailing list''' - [mailto:archlinux-stable@freelists.org archlinux-stable@freelists.org] Send e-mail with the subject 'signup'<br><br />
<br />
===Project Volunteers===<br />
<br />
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.<br />
<br />
Currently, the project has recruited these members:<br />
<br />
* nagoola - Project Management tasks / Communication. Also programming or package maintenance.<br />
* Nihathrael - Project Management / Programming / Documentation / Homepage / Package maintenance<br />
* rxKaffee - Programming / Provides testing server / Package maintenance<br />
* ibendiben - Coming soon, yet to decide<br />
* Misfit138 - Wrote this page-I am above average with English. Below average at GNU/Linux.<br />
* Basn - Packager<br />
* sixty-four-bit - Packager<br />
* AndyRTR - technical adviser, moderation / coordination if wanted/needed, maybe some packaging for core stuff<br />
* my64<br />
* hussam<br />
<br />
(Please add/remove your name as appropriate and state briefly what you are qualified to offer the project.)<br />
<br />
===Project Status===<br />
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.<br><br />
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.<br />
<br />
===Methodology===<br />
<br />
section has been modified<br />
[[User:Nihathrael|Nihathrael]] 10:07 am, 15 January 2008 (EST)<br />
[[User:sixty-four-bit|sixty-four-bit]] 10:03 pm, 15 January 2008 (EST): satisfy concerns from andyrtr and ise<br />
Please advise on this issue.<br />
<br />
After some discussion on IRC the following approach has been formed:<br />
<br />
# 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)] <br><br><br />
# 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.<br><br><br />
#* Packages will be updated if for one of the following reasons:<br><br />
#*# A major package update is released upstream, which has proven to be stable and bug/security fixed over time<br><br />
#*#* In case an upgrade needs human interaction the package is updated with the help of the project's own <b>"secure-install-script"</b>, which will be explained later, in section below.<br><br><br />
#*# A minor package update is released upstream that provides a bug/security fix and is considered stable.<br><br><br />
#*# 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.<br><br />
<br><br><br />
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...<br><br> <br />
<b>Special programs needed:</b> These are just the early design goals, please join the discussion IRC - irc.freenode.net #archlinux-stable<br> <br />
# 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)<br><br><br />
# 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.<br>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)<br><br><br />
# 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)<br />
<br />
==Sandbox==<br />
<br />
Crouse's Notes:<br />
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).<br />
<br />
Here is part of my auto-update script I use for my machines.... nothing earth shattering.<br />
I use a cronjob that does 2 things... <br />
<br />
1st downloads a pacman.conf file. Anything that I don't want updated is not updated.<br />
Using the pacman.conf file, an assortment of options present themselves to help keep a system "stable".<br />
Examples:<br />
<br />
IgnorePkg = kernel26<br />
NoUpgrade = etc/lilo.conf boot/grub/menu.lst<br />
HoldPkg = pacman glibc<br />
<br />
<br />
Again, nothing earth shattering, but it does allow me to keep packages that are breaking things, out of the system until proven trustworthy.<br />
<br />
2nd runs an automatic update script (because I'm lazy and don't want to update a dozen plus machines all the time.<br />
Here is the code for that part:<br />
<br />
#Pacman update and logging starts here<br />
echo " " 2>&1 >> /var/log/client.UPDATELOG<br />
echo "#############################################################" 2>&1 >> /var/log/client.UPDATELOG<br />
echo -ne "ARCH CLIENT UPDATE: " 2>&1 >> /var/log/client.UPDATELOG; echo `date +"%D %r"` 2>&1 >> /var/log/client.UPDATELOG<br />
echo "#############################################################" 2>&1 >> /var/log/client.UPDATELOG<br />
# Uncomment here if you want pacman to automatically update this machine<br />
pacman -Syu --noprogressbar --noconfirm 2>&1 >> /var/log/client.UPDATELOG<br />
# If you use lilo, remember to also uncomment the next line<br />
# /sbin/lilo 2>&1 >> /var/log/client.UPDATELOG<br />
<br />
Sorry if this is a bit messy....... feel free to "clean-up" my wiki mess here at the end :)<br />
<br />
<br />
<br />
==Old Entries==<br />
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.<br />
<br />
===Methodology Possibilities===<br />
<br />
Several different methods of achieving the project goal have been proposed-<br />
<br />
They include:<br />
<br />
1. Loosely basing the stable branch on Slackware packaging- expand to clarify, discuss.<br />
a. Follow Slackware-Current<br />
1. Kernel 2.6.23.12<br />
b. Follow Slackware-Stable<br />
1. Kernel 2.6.21<br />
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.<br />
http://distrowatch.com/table.php?distribution=rubix<br />
Review: http://www.tuxmachines.org/node/4699<br />
<br />
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. <br />
<br />
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.<br />
<br />
4. Loosely basing the stable branch on the Frugalware methodology. (Expand to clarify.)<br />
<br />
5. No stable "release" per se, but rather, stable packages.<br />
<br />
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.<br />
''Submit a script here by pasting it below.''<br />
<br />
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.<br />
<br />
===Release-Cycle Ideas===<br />
<br />
<br />
There could be a [core-stable] repository. This repository contains all the packages the normal [core] repo contains. <br><br />
There are 3 possibilities/ideas:<br><br />
<br />
====Version A====<br />
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.<br><br />
Benefits:<br><br />
* Pretty much rock-solid core repository that is very unlikely to break during the 3 months it is used.<br><br />
Disadvantages:<br><br />
* A lot of work is required to back-port security fixes to the rather old packages.<br><br />
* Probably a huge update is required from one release to another.<br><br />
* No upstream improvements/new features are introduced during one release.<br><br />
<br />
====Version B====<br />
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.<br><br />
Benefits:<br><br />
* Stable core repository with very few/none update problems.<br><br />
* 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.<br><br />
* Almost no need to back-port security fixes(only for "problem-packages")<br><br />
Disadvantages:<br><br />
* Higher risk of making the stable repository unstable, by updating packages that cause unknown problems.<br><br />
* 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].<br />
====Version C====<br />
''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.''<br><br />
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). <br />
This is rather advanced and should not be the first thing to try.<br><br />
<br />
All of these are only ideas and need detailed thoughts. So feel free to add/change anything you like.<br />
<br />
<br />
<br />
'''Please feel free to add to or otherwise modify this project page and join the discussion at irc.freenode.net #archlinux-stable'''</div>Sixty-four-bithttps://wiki.archlinux.org/index.php?title=Arch_Linux_Stable&diff=35122Arch Linux Stable2008-01-16T14:11:09Z<p>Sixty-four-bit: /* Requirements */</p>
<hr />
<div>==Arch Linux Stable Branch/Snapshot==<br />
<br />
In reference to the discussion in [http://bbs.archlinux.org/viewtopic.php?id=41764&p=1 this] forum thread, the proposition has been put forth, initially by '''nagoola''', to provide a stable branch or snapshot of the Arch Linux distribution. <br />
<br />
===GOAL===<br />
<br />
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.<br />
<br />
===Concept===<br />
<br />
Why a stable branch? A general consensus has been formed, of the opinion that such a project will be advantageous in several ways:<br />
<br />
1. For the stability of workstations/production machines:<br />
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''."<br />
<br />
2. Desktops/Personal machines: <br />
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.<br />
<br />
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. <br />
<br />
===Definition===<br />
<br />
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.<br />
<br />
===Requirements===<br />
<br />
'''Communication is a must between all involved.'''<br />
<br />
<br />
1. Project Leader - Delegate tasks and project direction.<br />
<br />
2. Packagers - Choosing and handling packages to add to the snapshot repository.<br />
<br />
3. Testers - Testing the stability of packages, logistics, and assistance.<br />
<br />
4. Repository - Will require a server.<br />
<br />
5. (Possibly) Scripting - submit a prototype script below, which can tweak the client (user) pacman.conf to ignorepkg= ''unstablepkg''<br />
<br />
===Communication===<br />
<br />
'''IRC''' - irc.freenode.net #archlinux-stable<br><br />
'''Mailing list''' - archlinux-stable@freelists.org Send e-mail with the subject 'signup'<br><br />
<br />
===Project Volunteers===<br />
<br />
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.<br />
<br />
Currently, the project has recruited these members:<br />
<br />
* nagoola - Project Management tasks / Communication. Also programming or package maintenance.<br />
* Nihathrael - Project Management / Programming / Documentation / Homepage / Package maintenance<br />
* rxKaffee - Programming / Provides testing server / Package maintenance<br />
* ibendiben - Coming soon, yet to decide<br />
* Misfit138 - Wrote this page-I am above average with English. Below average at GNU/Linux.<br />
* Basn - Packager<br />
* sixty-four-bit - Packager<br />
* AndyRTR - technical adviser, moderation / coordination if wanted/needed, maybe some packaging for core stuff<br />
* my64<br />
* hussam<br />
<br />
(Please add/remove your name as appropriate and state briefly what you are qualified to offer the project.)<br />
<br />
===Project Status===<br />
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.<br><br />
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.<br />
<br />
===Methodology===<br />
<br />
section has been modified<br />
[[User:Nihathrael|Nihathrael]] 10:07 am, 15 January 2008 (EST)<br />
[[User:sixty-four-bit|sixty-four-bit]] 10:03 pm, 15 January 2008 (EST): satisfy concerns from andyrtr and ise<br />
Please advise on this issue.<br />
<br />
After some discussion on IRC the following approach has been formed:<br />
<br />
# 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)] <br><br><br />
# 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.<br><br><br />
#* Packages will be updated if for one of the following reasons:<br><br />
#*# A major package update is released upstream, which has proven to be stable and bug/security fixed over time<br><br />
#*#* In case an upgrade needs human interaction the package is updated with the help of the project's own <b>"secure-install-script"</b>, which will be explained later, in section below.<br><br><br />
#*# A minor package update is released upstream that provides a bug/security fix and is considered stable.<br><br><br />
#*# 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.<br><br />
<br><br><br />
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...<br><br> <br />
<b>Special programs needed:</b> These are just the early design goals, please join the discussion IRC - irc.freenode.net #archlinux-stable<br> <br />
# 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)<br><br><br />
# 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.<br>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)<br><br><br />
# 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)<br />
<br />
==Sandbox==<br />
<br />
Crouse's Notes:<br />
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).<br />
<br />
Here is part of my auto-update script I use for my machines.... nothing earth shattering.<br />
I use a cronjob that does 2 things... <br />
<br />
1st downloads a pacman.conf file. Anything that I don't want updated is not updated.<br />
Using the pacman.conf file, an assortment of options present themselves to help keep a system "stable".<br />
Examples:<br />
<br />
IgnorePkg = kernel26<br />
NoUpgrade = etc/lilo.conf boot/grub/menu.lst<br />
HoldPkg = pacman glibc<br />
<br />
<br />
Again, nothing earth shattering, but it does allow me to keep packages that are breaking things, out of the system until proven trustworthy.<br />
<br />
2nd runs an automatic update script (because I'm lazy and don't want to update a dozen plus machines all the time.<br />
Here is the code for that part:<br />
<br />
#Pacman update and logging starts here<br />
echo " " 2>&1 >> /var/log/client.UPDATELOG<br />
echo "#############################################################" 2>&1 >> /var/log/client.UPDATELOG<br />
echo -ne "ARCH CLIENT UPDATE: " 2>&1 >> /var/log/client.UPDATELOG; echo `date +"%D %r"` 2>&1 >> /var/log/client.UPDATELOG<br />
echo "#############################################################" 2>&1 >> /var/log/client.UPDATELOG<br />
# Uncomment here if you want pacman to automatically update this machine<br />
pacman -Syu --noprogressbar --noconfirm 2>&1 >> /var/log/client.UPDATELOG<br />
# If you use lilo, remember to also uncomment the next line<br />
# /sbin/lilo 2>&1 >> /var/log/client.UPDATELOG<br />
<br />
Sorry if this is a bit messy....... feel free to "clean-up" my wiki mess here at the end :)<br />
<br />
<br />
<br />
==Old Entries==<br />
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.<br />
<br />
===Methodology Possibilities===<br />
<br />
Several different methods of achieving the project goal have been proposed-<br />
<br />
They include:<br />
<br />
1. Loosely basing the stable branch on Slackware packaging- expand to clarify, discuss.<br />
a. Follow Slackware-Current<br />
1. Kernel 2.6.23.12<br />
b. Follow Slackware-Stable<br />
1. Kernel 2.6.21<br />
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.<br />
http://distrowatch.com/table.php?distribution=rubix<br />
Review: http://www.tuxmachines.org/node/4699<br />
<br />
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. <br />
<br />
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.<br />
<br />
4. Loosely basing the stable branch on the Frugalware methodology. (Expand to clarify.)<br />
<br />
5. No stable "release" per se, but rather, stable packages.<br />
<br />
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.<br />
''Submit a script here by pasting it below.''<br />
<br />
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.<br />
<br />
===Release-Cycle Ideas===<br />
<br />
<br />
There could be a [core-stable] repository. This repository contains all the packages the normal [core] repo contains. <br><br />
There are 3 possibilities/ideas:<br><br />
<br />
====Version A====<br />
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.<br><br />
Benefits:<br><br />
* Pretty much rock-solid core repository that is very unlikely to break during the 3 months it is used.<br><br />
Disadvantages:<br><br />
* A lot of work is required to back-port security fixes to the rather old packages.<br><br />
* Probably a huge update is required from one release to another.<br><br />
* No upstream improvements/new features are introduced during one release.<br><br />
<br />
====Version B====<br />
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.<br><br />
Benefits:<br><br />
* Stable core repository with very few/none update problems.<br><br />
* 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.<br><br />
* Almost no need to back-port security fixes(only for "problem-packages")<br><br />
Disadvantages:<br><br />
* Higher risk of making the stable repository unstable, by updating packages that cause unknown problems.<br><br />
* 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].<br />
====Version C====<br />
''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.''<br><br />
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). <br />
This is rather advanced and should not be the first thing to try.<br><br />
<br />
All of these are only ideas and need detailed thoughts. So feel free to add/change anything you like.<br />
<br />
<br />
<br />
'''Please feel free to add to or otherwise modify this project page and join the discussion at irc.freenode.net #archlinux-stable'''</div>Sixty-four-bithttps://wiki.archlinux.org/index.php?title=Arch_Linux_Stable&diff=35115Arch Linux Stable2008-01-16T03:09:12Z<p>Sixty-four-bit: /* Methodology */</p>
<hr />
<div>==Arch Linux Stable Branch/Snapshot==<br />
<br />
In reference to the discussion in [http://bbs.archlinux.org/viewtopic.php?id=41764&p=1 this] forum thread, the proposition has been put forth, initially by '''nagoola''', to provide a stable branch or snapshot of the Arch Linux distribution. <br />
<br />
===GOAL===<br />
<br />
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.<br />
<br />
===Concept===<br />
<br />
Why a stable branch? A general consensus has been formed, of the opinion that such a project will be advantageous in several ways:<br />
<br />
1. For the stability of workstations/production machines:<br />
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''."<br />
<br />
2. Desktops/Personal machines: <br />
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.<br />
<br />
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. <br />
<br />
===Definition===<br />
<br />
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.<br />
<br />
===Requirements===<br />
<br />
'''Communication is a must between all involved.'''<br />
<br />
1. Project Leader - Delegate tasks and project direction.<br />
<br />
2. Packagers - Choosing and handling packages to add to the snapshot repository.<br />
<br />
3. Testers - Testing the stability of packages, logistics, and assistance.<br />
<br />
4. Repository - Will require a server.<br />
<br />
5. (Possibly) Scripting - submit a prototype script below, which can tweak the client (user) pacman.conf to ignorepkg= ''unstablepkg''<br />
<br />
===Project Volunteers===<br />
<br />
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.<br />
<br />
Currently, the project has recruited these members:<br />
<br />
* nagoola - Project Management tasks / Communication. Also programming or package maintenance.<br />
* Nihathrael - Project Management / Programming / Documentation / Homepage / Package maintenance<br />
* rxKaffee - Programming / Provides testing server / Package maintenance<br />
* ibendiben - Coming soon, yet to decide<br />
* Misfit138 - Wrote this page-I am above average with English. Below average at GNU/Linux.<br />
* Basn - Packager<br />
* sixty-four-bit - Packager<br />
* AndyRTR - technical adviser, moderation / coordination if wanted/needed, maybe some packaging for core stuff<br />
* my64<br />
* hussam<br />
<br />
(Please add/remove your name as appropriate and state briefly what you are qualified to offer the project.)<br />
<br />
===Project Status===<br />
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.<br><br />
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.<br />
<br />
===Methodology===<br />
<br />
section has been modified<br />
[[User:Nihathrael|Nihathrael]] 10:07 am, 15 January 2008 (EST)<br />
[[User:sixty-four-bit|sixty-four-bit]] 10:03 pm, 15 January 2008 (EST): satisfy concerns from andyrtr and ise<br />
Please advise on this issue.<br />
<br />
After some discussion on IRC the following approach has been formed:<br />
<br />
# 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)] <br><br><br />
# 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.<br><br><br />
#* Packages will be updated if for one of the following reasons:<br><br />
#*# A major package update is released upstream, which has proven to be stable and bug/security fixed over time<br><br />
#*#* In case an upgrade needs human interaction the package is updated with the help of the project's own <b>"secure-install-script"</b>, which will be explained later, in section below.<br><br><br />
#*# A minor package update is released upstream that provides a bug/security fix and is considered stable.<br><br><br />
#*# 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.<br><br />
<br><br><br />
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...<br><br> <br />
<b>Special programs needed:</b> These are just the early design goals, please join the discussion IRC - irc.freenode.net #archlinux-stable<br> <br />
# 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)<br><br><br />
# 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.<br>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)<br><br><br />
# 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)<br />
<br />
==Sandbox==<br />
<br />
Crouse's Notes:<br />
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).<br />
<br />
Here is part of my auto-update script I use for my machines.... nothing earth shattering.<br />
I use a cronjob that does 2 things... <br />
<br />
1st downloads a pacman.conf file. Anything that I don't want updated is not updated.<br />
Using the pacman.conf file, an assortment of options present themselves to help keep a system "stable".<br />
Examples:<br />
<br />
IgnorePkg = kernel26<br />
NoUpgrade = etc/lilo.conf boot/grub/menu.lst<br />
HoldPkg = pacman glibc<br />
<br />
<br />
Again, nothing earth shattering, but it does allow me to keep packages that are breaking things, out of the system until proven trustworthy.<br />
<br />
2nd runs an automatic update script (because I'm lazy and don't want to update a dozen plus machines all the time.<br />
Here is the code for that part:<br />
<br />
#Pacman update and logging starts here<br />
echo " " 2>&1 >> /var/log/client.UPDATELOG<br />
echo "#############################################################" 2>&1 >> /var/log/client.UPDATELOG<br />
echo -ne "ARCH CLIENT UPDATE: " 2>&1 >> /var/log/client.UPDATELOG; echo `date +"%D %r"` 2>&1 >> /var/log/client.UPDATELOG<br />
echo "#############################################################" 2>&1 >> /var/log/client.UPDATELOG<br />
# Uncomment here if you want pacman to automatically update this machine<br />
pacman -Syu --noprogressbar --noconfirm 2>&1 >> /var/log/client.UPDATELOG<br />
# If you use lilo, remember to also uncomment the next line<br />
# /sbin/lilo 2>&1 >> /var/log/client.UPDATELOG<br />
<br />
Sorry if this is a bit messy....... feel free to "clean-up" my wiki mess here at the end :)<br />
<br />
<br />
<br />
==Old Entries==<br />
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.<br />
<br />
===Methodology Possibilities===<br />
<br />
Several different methods of achieving the project goal have been proposed-<br />
<br />
They include:<br />
<br />
1. Loosely basing the stable branch on Slackware packaging- expand to clarify, discuss.<br />
a. Follow Slackware-Current<br />
1. Kernel 2.6.23.12<br />
b. Follow Slackware-Stable<br />
1. Kernel 2.6.21<br />
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.<br />
http://distrowatch.com/table.php?distribution=rubix<br />
Review: http://www.tuxmachines.org/node/4699<br />
<br />
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. <br />
<br />
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.<br />
<br />
4. Loosely basing the stable branch on the Frugalware methodology. (Expand to clarify.)<br />
<br />
5. No stable "release" per se, but rather, stable packages.<br />
<br />
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.<br />
''Submit a script here by pasting it below.''<br />
<br />
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.<br />
<br />
===Release-Cycle Ideas===<br />
<br />
<br />
There could be a [core-stable] repository. This repository contains all the packages the normal [core] repo contains. <br><br />
There are 3 possibilities/ideas:<br><br />
<br />
====Version A====<br />
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.<br><br />
Benefits:<br><br />
* Pretty much rock-solid core repository that is very unlikely to break during the 3 months it is used.<br><br />
Disadvantages:<br><br />
* A lot of work is required to back-port security fixes to the rather old packages.<br><br />
* Probably a huge update is required from one release to another.<br><br />
* No upstream improvements/new features are introduced during one release.<br><br />
<br />
====Version B====<br />
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.<br><br />
Benefits:<br><br />
* Stable core repository with very few/none update problems.<br><br />
* 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.<br><br />
* Almost no need to back-port security fixes(only for "problem-packages")<br><br />
Disadvantages:<br><br />
* Higher risk of making the stable repository unstable, by updating packages that cause unknown problems.<br><br />
* 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].<br />
====Version C====<br />
''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.''<br><br />
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). <br />
This is rather advanced and should not be the first thing to try.<br><br />
<br />
All of these are only ideas and need detailed thoughts. So feel free to add/change anything you like.<br />
<br />
<br />
<br />
'''Please feel free to add to or otherwise modify this project page and join the discussion at irc.freenode.net #archlinux-stable'''</div>Sixty-four-bithttps://wiki.archlinux.org/index.php?title=Arch_Linux_Stable&diff=35114Arch Linux Stable2008-01-16T03:05:53Z<p>Sixty-four-bit: /* Project Status */</p>
<hr />
<div>==Arch Linux Stable Branch/Snapshot==<br />
<br />
In reference to the discussion in [http://bbs.archlinux.org/viewtopic.php?id=41764&p=1 this] forum thread, the proposition has been put forth, initially by '''nagoola''', to provide a stable branch or snapshot of the Arch Linux distribution. <br />
<br />
===GOAL===<br />
<br />
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.<br />
<br />
===Concept===<br />
<br />
Why a stable branch? A general consensus has been formed, of the opinion that such a project will be advantageous in several ways:<br />
<br />
1. For the stability of workstations/production machines:<br />
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''."<br />
<br />
2. Desktops/Personal machines: <br />
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.<br />
<br />
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. <br />
<br />
===Definition===<br />
<br />
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.<br />
<br />
===Requirements===<br />
<br />
'''Communication is a must between all involved.'''<br />
<br />
1. Project Leader - Delegate tasks and project direction.<br />
<br />
2. Packagers - Choosing and handling packages to add to the snapshot repository.<br />
<br />
3. Testers - Testing the stability of packages, logistics, and assistance.<br />
<br />
4. Repository - Will require a server.<br />
<br />
5. (Possibly) Scripting - submit a prototype script below, which can tweak the client (user) pacman.conf to ignorepkg= ''unstablepkg''<br />
<br />
===Project Volunteers===<br />
<br />
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.<br />
<br />
Currently, the project has recruited these members:<br />
<br />
* nagoola - Project Management tasks / Communication. Also programming or package maintenance.<br />
* Nihathrael - Project Management / Programming / Documentation / Homepage / Package maintenance<br />
* rxKaffee - Programming / Provides testing server / Package maintenance<br />
* ibendiben - Coming soon, yet to decide<br />
* Misfit138 - Wrote this page-I am above average with English. Below average at GNU/Linux.<br />
* Basn - Packager<br />
* sixty-four-bit - Packager<br />
* AndyRTR - technical adviser, moderation / coordination if wanted/needed, maybe some packaging for core stuff<br />
* my64<br />
* hussam<br />
<br />
(Please add/remove your name as appropriate and state briefly what you are qualified to offer the project.)<br />
<br />
===Project Status===<br />
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.<br><br />
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.<br />
<br />
===Methodology===<br />
<br />
section has been modified<br />
[[User:Nihathrael|Nihathrael]] 10:07 am, 15 January 2008 (EST)<br />
[[User:sixty-four-bit|sixty-four-bit]] 10:03 pm, 15 January 2008 (EST): satisfy concerns from andytrtr and ise<br />
Please advise on this issue.<br />
<br />
After some discussion on IRC the following approach has been formed:<br />
<br />
# 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)] <br><br><br />
# 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.<br><br><br />
#* Packages will be updated if for one of the following reasons:<br><br />
#*# A major package update is released upstream, which has proven to be stable and bug/security fixed over time<br><br />
#*#* In case an upgrade needs human interaction the package is updated with the help of the project's own <b>"secure-install-script"</b>, which will be explained later, in section below.<br><br><br />
#*# A minor package update is released upstream that provides a bug/security fix and is considered stable.<br><br><br />
#*# 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.<br><br />
<br><br><br />
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...<br><br> <br />
<b>Special programs needed:</b> These are just the early design goals, please join the discussion IRC - irc.freenode.net #archlinux-stable<br> <br />
# 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)<br><br><br />
# 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.<br>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)<br><br><br />
# 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)<br />
<br />
==Sandbox==<br />
<br />
Crouse's Notes:<br />
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).<br />
<br />
Here is part of my auto-update script I use for my machines.... nothing earth shattering.<br />
I use a cronjob that does 2 things... <br />
<br />
1st downloads a pacman.conf file. Anything that I don't want updated is not updated.<br />
Using the pacman.conf file, an assortment of options present themselves to help keep a system "stable".<br />
Examples:<br />
<br />
IgnorePkg = kernel26<br />
NoUpgrade = etc/lilo.conf boot/grub/menu.lst<br />
HoldPkg = pacman glibc<br />
<br />
<br />
Again, nothing earth shattering, but it does allow me to keep packages that are breaking things, out of the system until proven trustworthy.<br />
<br />
2nd runs an automatic update script (because I'm lazy and don't want to update a dozen plus machines all the time.<br />
Here is the code for that part:<br />
<br />
#Pacman update and logging starts here<br />
echo " " 2>&1 >> /var/log/client.UPDATELOG<br />
echo "#############################################################" 2>&1 >> /var/log/client.UPDATELOG<br />
echo -ne "ARCH CLIENT UPDATE: " 2>&1 >> /var/log/client.UPDATELOG; echo `date +"%D %r"` 2>&1 >> /var/log/client.UPDATELOG<br />
echo "#############################################################" 2>&1 >> /var/log/client.UPDATELOG<br />
# Uncomment here if you want pacman to automatically update this machine<br />
pacman -Syu --noprogressbar --noconfirm 2>&1 >> /var/log/client.UPDATELOG<br />
# If you use lilo, remember to also uncomment the next line<br />
# /sbin/lilo 2>&1 >> /var/log/client.UPDATELOG<br />
<br />
Sorry if this is a bit messy....... feel free to "clean-up" my wiki mess here at the end :)<br />
<br />
<br />
<br />
==Old Entries==<br />
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.<br />
<br />
===Methodology Possibilities===<br />
<br />
Several different methods of achieving the project goal have been proposed-<br />
<br />
They include:<br />
<br />
1. Loosely basing the stable branch on Slackware packaging- expand to clarify, discuss.<br />
a. Follow Slackware-Current<br />
1. Kernel 2.6.23.12<br />
b. Follow Slackware-Stable<br />
1. Kernel 2.6.21<br />
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.<br />
http://distrowatch.com/table.php?distribution=rubix<br />
Review: http://www.tuxmachines.org/node/4699<br />
<br />
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. <br />
<br />
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.<br />
<br />
4. Loosely basing the stable branch on the Frugalware methodology. (Expand to clarify.)<br />
<br />
5. No stable "release" per se, but rather, stable packages.<br />
<br />
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.<br />
''Submit a script here by pasting it below.''<br />
<br />
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.<br />
<br />
===Release-Cycle Ideas===<br />
<br />
<br />
There could be a [core-stable] repository. This repository contains all the packages the normal [core] repo contains. <br><br />
There are 3 possibilities/ideas:<br><br />
<br />
====Version A====<br />
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.<br><br />
Benefits:<br><br />
* Pretty much rock-solid core repository that is very unlikely to break during the 3 months it is used.<br><br />
Disadvantages:<br><br />
* A lot of work is required to back-port security fixes to the rather old packages.<br><br />
* Probably a huge update is required from one release to another.<br><br />
* No upstream improvements/new features are introduced during one release.<br><br />
<br />
====Version B====<br />
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.<br><br />
Benefits:<br><br />
* Stable core repository with very few/none update problems.<br><br />
* 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.<br><br />
* Almost no need to back-port security fixes(only for "problem-packages")<br><br />
Disadvantages:<br><br />
* Higher risk of making the stable repository unstable, by updating packages that cause unknown problems.<br><br />
* 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].<br />
====Version C====<br />
''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.''<br><br />
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). <br />
This is rather advanced and should not be the first thing to try.<br><br />
<br />
All of these are only ideas and need detailed thoughts. So feel free to add/change anything you like.<br />
<br />
<br />
<br />
'''Please feel free to add to or otherwise modify this project page and join the discussion at irc.freenode.net #archlinux-stable'''</div>Sixty-four-bithttps://wiki.archlinux.org/index.php?title=Arch_Linux_Stable&diff=35113Arch Linux Stable2008-01-16T02:56:46Z<p>Sixty-four-bit: /* Methodology */</p>
<hr />
<div>==Arch Linux Stable Branch/Snapshot==<br />
<br />
In reference to the discussion in [http://bbs.archlinux.org/viewtopic.php?id=41764&p=1 this] forum thread, the proposition has been put forth, initially by '''nagoola''', to provide a stable branch or snapshot of the Arch Linux distribution. <br />
<br />
===GOAL===<br />
<br />
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.<br />
<br />
===Concept===<br />
<br />
Why a stable branch? A general consensus has been formed, of the opinion that such a project will be advantageous in several ways:<br />
<br />
1. For the stability of workstations/production machines:<br />
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''."<br />
<br />
2. Desktops/Personal machines: <br />
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.<br />
<br />
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. <br />
<br />
===Definition===<br />
<br />
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.<br />
<br />
===Requirements===<br />
<br />
'''Communication is a must between all involved.'''<br />
<br />
1. Project Leader - Delegate tasks and project direction.<br />
<br />
2. Packagers - Choosing and handling packages to add to the snapshot repository.<br />
<br />
3. Testers - Testing the stability of packages, logistics, and assistance.<br />
<br />
4. Repository - Will require a server.<br />
<br />
5. (Possibly) Scripting - submit a prototype script below, which can tweak the client (user) pacman.conf to ignorepkg= ''unstablepkg''<br />
<br />
===Project Volunteers===<br />
<br />
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.<br />
<br />
Currently, the project has recruited these members:<br />
<br />
* nagoola - Project Management tasks / Communication. Also programming or package maintenance.<br />
* Nihathrael - Project Management / Programming / Documentation / Homepage / Package maintenance<br />
* rxKaffee - Programming / Provides testing server / Package maintenance<br />
* ibendiben - Coming soon, yet to decide<br />
* Misfit138 - Wrote this page-I am above average with English. Below average at GNU/Linux.<br />
* Basn - Packager<br />
* sixty-four-bit - Packager<br />
* AndyRTR - technical adviser, moderation / coordination if wanted/needed, maybe some packaging for core stuff<br />
* my64<br />
* hussam<br />
<br />
(Please add/remove your name as appropriate and state briefly what you are qualified to offer the project.)<br />
<br />
===Project Status===<br />
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.<br><br />
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.<br />
The methodology section has been updated. <br />
[[User:Nihathrael|Nihathrael]] 10:07, 15 January 2008 (EST)<br />
<br />
===Methodology===<br><br />
''this section has been modified 1/15/08: sixty-four-bit to satisfy concerns from andytrtr and ise: please advise on these changes''<br><br />
<br />
After some discussion on IRC the following approach has been formed:<br />
<br />
# 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)] <br><br><br />
# 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.<br><br><br />
#* Packages will be updated if for one of the following reasons:<br><br />
#*# A major package update is released upstream, which has proven to be stable and bug/security fixed over time<br><br />
#*#* In case an upgrade needs human interaction the package is updated with the help of the project's own <b>"secure-install-script"</b>, which will be explained later, in section below.<br><br><br />
#*# A minor package update is released upstream that provides a bug/security fix and is considered stable.<br><br><br />
#*# 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.<br><br />
<br><br><br />
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...<br><br> <br />
<b>Special programs needed:</b> These are just the early design goals, please join the discussion IRC - irc.freenode.net #archlinux-stable<br> <br />
# 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)<br><br><br />
# 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.<br>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)<br><br><br />
# 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)<br />
<br />
==Sandbox==<br />
<br />
Crouse's Notes:<br />
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).<br />
<br />
Here is part of my auto-update script I use for my machines.... nothing earth shattering.<br />
I use a cronjob that does 2 things... <br />
<br />
1st downloads a pacman.conf file. Anything that I don't want updated is not updated.<br />
Using the pacman.conf file, an assortment of options present themselves to help keep a system "stable".<br />
Examples:<br />
<br />
IgnorePkg = kernel26<br />
NoUpgrade = etc/lilo.conf boot/grub/menu.lst<br />
HoldPkg = pacman glibc<br />
<br />
<br />
Again, nothing earth shattering, but it does allow me to keep packages that are breaking things, out of the system until proven trustworthy.<br />
<br />
2nd runs an automatic update script (because I'm lazy and don't want to update a dozen plus machines all the time.<br />
Here is the code for that part:<br />
<br />
#Pacman update and logging starts here<br />
echo " " 2>&1 >> /var/log/client.UPDATELOG<br />
echo "#############################################################" 2>&1 >> /var/log/client.UPDATELOG<br />
echo -ne "ARCH CLIENT UPDATE: " 2>&1 >> /var/log/client.UPDATELOG; echo `date +"%D %r"` 2>&1 >> /var/log/client.UPDATELOG<br />
echo "#############################################################" 2>&1 >> /var/log/client.UPDATELOG<br />
# Uncomment here if you want pacman to automatically update this machine<br />
pacman -Syu --noprogressbar --noconfirm 2>&1 >> /var/log/client.UPDATELOG<br />
# If you use lilo, remember to also uncomment the next line<br />
# /sbin/lilo 2>&1 >> /var/log/client.UPDATELOG<br />
<br />
Sorry if this is a bit messy....... feel free to "clean-up" my wiki mess here at the end :)<br />
<br />
<br />
<br />
==Old Entries==<br />
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.<br />
<br />
===Methodology Possibilities===<br />
<br />
Several different methods of achieving the project goal have been proposed-<br />
<br />
They include:<br />
<br />
1. Loosely basing the stable branch on Slackware packaging- expand to clarify, discuss.<br />
a. Follow Slackware-Current<br />
1. Kernel 2.6.23.12<br />
b. Follow Slackware-Stable<br />
1. Kernel 2.6.21<br />
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.<br />
http://distrowatch.com/table.php?distribution=rubix<br />
Review: http://www.tuxmachines.org/node/4699<br />
<br />
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. <br />
<br />
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.<br />
<br />
4. Loosely basing the stable branch on the Frugalware methodology. (Expand to clarify.)<br />
<br />
5. No stable "release" per se, but rather, stable packages.<br />
<br />
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.<br />
''Submit a script here by pasting it below.''<br />
<br />
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.<br />
<br />
===Release-Cycle Ideas===<br />
<br />
<br />
There could be a [core-stable] repository. This repository contains all the packages the normal [core] repo contains. <br><br />
There are 3 possibilities/ideas:<br><br />
<br />
====Version A====<br />
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.<br><br />
Benefits:<br><br />
* Pretty much rock-solid core repository that is very unlikely to break during the 3 months it is used.<br><br />
Disadvantages:<br><br />
* A lot of work is required to back-port security fixes to the rather old packages.<br><br />
* Probably a huge update is required from one release to another.<br><br />
* No upstream improvements/new features are introduced during one release.<br><br />
<br />
====Version B====<br />
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.<br><br />
Benefits:<br><br />
* Stable core repository with very few/none update problems.<br><br />
* 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.<br><br />
* Almost no need to back-port security fixes(only for "problem-packages")<br><br />
Disadvantages:<br><br />
* Higher risk of making the stable repository unstable, by updating packages that cause unknown problems.<br><br />
* 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].<br />
====Version C====<br />
''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.''<br><br />
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). <br />
This is rather advanced and should not be the first thing to try.<br><br />
<br />
All of these are only ideas and need detailed thoughts. So feel free to add/change anything you like.<br />
<br />
<br />
<br />
'''Please feel free to add to or otherwise modify this project page and join the discussion at irc.freenode.net #archlinux-stable'''</div>Sixty-four-bithttps://wiki.archlinux.org/index.php?title=Arch_Linux_Stable&diff=35074Arch Linux Stable2008-01-15T17:08:55Z<p>Sixty-four-bit: /* Methodology */</p>
<hr />
<div>==Arch Linux Stable Branch/Snapshot==<br />
<br />
In reference to the discussion in [http://bbs.archlinux.org/viewtopic.php?id=41764&p=1 this] forum thread, the proposition has been put forth, initially by '''nagoola''', to provide a stable branch or snapshot of the Arch Linux distribution. <br />
<br />
===GOAL===<br />
<br />
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.<br />
<br />
===Concept===<br />
<br />
Why a stable branch? A general consensus has been formed, of the opinion that such a project will be advantageous in several ways:<br />
<br />
1. For the stability of workstations/production machines:<br />
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''."<br />
<br />
2. Desktops/Personal machines: <br />
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.<br />
<br />
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. <br />
<br />
===Definition===<br />
<br />
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.<br />
<br />
===Requirements===<br />
<br />
'''Communication is a must between all involved.'''<br />
<br />
1. Project Leader - Delegate tasks and project direction.<br />
<br />
2. Packagers - Choosing and handling packages to add to the snapshot repository.<br />
<br />
3. Testers - Testing the stability of packages, logistics, and assistance.<br />
<br />
4. Repository - Will require a server.<br />
<br />
5. (Possibly) Scripting - submit a prototype script below, which can tweak the client (user) pacman.conf to ignorepkg= ''unstablepkg''<br />
<br />
===Project Volunteers===<br />
<br />
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.<br />
<br />
Currently, the project has recruited these members:<br />
<br />
* nagoola - Project Management tasks / Communication. Also programming or package maintenance.<br />
* Nihathrael - Project Management / Programming / Documentation / Homepage / Package maintenance<br />
* rxKaffee - Programming / Provides testing server / Package maintenance<br />
* ibendiben - Coming soon, yet to decide<br />
* Misfit138 - Wrote this page-I am above average with English. Below average at GNU/Linux.<br />
* Basn - Packager<br />
* sixty-four-bit - Packager<br />
* AndyRTR - technical adviser, moderation / coordination if wanted/needed, maybe some packaging for core stuff<br />
* my64<br />
* hussam<br />
<br />
(Please add/remove your name as appropriate and state briefly what you are qualified to offer the project.)<br />
<br />
===Project Status===<br />
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.<br><br />
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.<br />
The methodology section has been updated. <br />
[[User:Nihathrael|Nihathrael]] 10:07, 15 January 2008 (EST)<br />
<br />
===Methodology===<br />
<br />
After some discussion on IRC the following approach has been formed:<br />
<br />
# 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)] <br><br><br />
# Packages will be updated if for one of the following reasons:<br><br />
## A major package update is released upstream, which has proven to be stable and bug/security fixed over time(~1-4 weeks)<br><br />
##* In case an upgrade needs human interaction the package is updated with the help of the project's own <b>"secure-install-script"</b>, which will be explained in an extra section.<br />
## A minor package update is released upstream that provides a bug/security fix and is considered stable.<br><br><br />
# Critical packages, like the kernel for example, will be updated when approved by the maintenance team<br><br />
<br><br />
<b>Special programs needed:</b> These are just the early design goals, please join the discussion IRC - irc.freenode.net #archlinux-stable<br> <br />
# 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)<br><br><br />
# 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.<br>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)<br><br><br />
# 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)<br />
<br />
==Sandbox==<br />
<br />
Crouse's Notes:<br />
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).<br />
<br />
Here is part of my auto-update script I use for my machines.... nothing earth shattering.<br />
I use a cronjob that does 2 things... <br />
<br />
1st downloads a pacman.conf file. Anything that I don't want updated is not updated.<br />
Using the pacman.conf file, an assortment of options present themselves to help keep a system "stable".<br />
Examples:<br />
<br />
IgnorePkg = kernel26<br />
NoUpgrade = etc/lilo.conf boot/grub/menu.lst<br />
HoldPkg = pacman glibc<br />
<br />
<br />
Again, nothing earth shattering, but it does allow me to keep packages that are breaking things, out of the system until proven trustworthy.<br />
<br />
2nd runs an automatic update script (because I'm lazy and don't want to update a dozen plus machines all the time.<br />
Here is the code for that part:<br />
<br />
#Pacman update and logging starts here<br />
echo " " 2>&1 >> /var/log/client.UPDATELOG<br />
echo "#############################################################" 2>&1 >> /var/log/client.UPDATELOG<br />
echo -ne "ARCH CLIENT UPDATE: " 2>&1 >> /var/log/client.UPDATELOG; echo `date +"%D %r"` 2>&1 >> /var/log/client.UPDATELOG<br />
echo "#############################################################" 2>&1 >> /var/log/client.UPDATELOG<br />
# Uncomment here if you want pacman to automatically update this machine<br />
pacman -Syu --noprogressbar --noconfirm 2>&1 >> /var/log/client.UPDATELOG<br />
# If you use lilo, remember to also uncomment the next line<br />
# /sbin/lilo 2>&1 >> /var/log/client.UPDATELOG<br />
<br />
Sorry if this is a bit messy....... feel free to "clean-up" my wiki mess here at the end :)<br />
<br />
<br />
<br />
==Old Entries==<br />
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.<br />
<br />
===Methodology Possibilities===<br />
<br />
Several different methods of achieving the project goal have been proposed-<br />
<br />
They include:<br />
<br />
1. Loosely basing the stable branch on Slackware packaging- expand to clarify, discuss.<br />
a. Follow Slackware-Current<br />
1. Kernel 2.6.23.12<br />
b. Follow Slackware-Stable<br />
1. Kernel 2.6.21<br />
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.<br />
http://distrowatch.com/table.php?distribution=rubix<br />
Review: http://www.tuxmachines.org/node/4699<br />
<br />
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. <br />
<br />
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.<br />
<br />
4. Loosely basing the stable branch on the Frugalware methodology. (Expand to clarify.)<br />
<br />
5. No stable "release" per se, but rather, stable packages.<br />
<br />
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.<br />
''Submit a script here by pasting it below.''<br />
<br />
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.<br />
<br />
===Release-Cycle Ideas===<br />
<br />
<br />
There could be a [core-stable] repository. This repository contains all the packages the normal [core] repo contains. <br><br />
There are 3 possibilities/ideas:<br><br />
<br />
====Version A====<br />
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.<br><br />
Benefits:<br><br />
* Pretty much rock-solid core repository that is very unlikely to break during the 3 months it is used.<br><br />
Disadvantages:<br><br />
* A lot of work is required to back-port security fixes to the rather old packages.<br><br />
* Probably a huge update is required from one release to another.<br><br />
* No upstream improvements/new features are introduced during one release.<br><br />
<br />
====Version B====<br />
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.<br><br />
Benefits:<br><br />
* Stable core repository with very few/none update problems.<br><br />
* 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.<br><br />
* Almost no need to back-port security fixes(only for "problem-packages")<br><br />
Disadvantages:<br><br />
* Higher risk of making the stable repository unstable, by updating packages that cause unknown problems.<br><br />
* 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].<br />
====Version C====<br />
''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.''<br><br />
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). <br />
This is rather advanced and should not be the first thing to try.<br><br />
<br />
All of these are only ideas and need detailed thoughts. So feel free to add/change anything you like.<br />
<br />
<br />
<br />
'''Please feel free to add to or otherwise modify this project page and join the discussion at irc.freenode.net #archlinux-stable'''</div>Sixty-four-bithttps://wiki.archlinux.org/index.php?title=Arch_Linux_Stable&diff=35070Arch Linux Stable2008-01-15T16:44:49Z<p>Sixty-four-bit: /* Methodology */</p>
<hr />
<div>==Arch Linux Stable Branch/Snapshot==<br />
<br />
In reference to the discussion in [http://bbs.archlinux.org/viewtopic.php?id=41764&p=1 this] forum thread, the proposition has been put forth, initially by '''nagoola''', to provide a stable branch or snapshot of the Arch Linux distribution. <br />
<br />
===GOAL===<br />
<br />
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.<br />
<br />
===Concept===<br />
<br />
Why a stable branch? A general consensus has been formed, of the opinion that such a project will be advantageous in several ways:<br />
<br />
1. For the stability of workstations/production machines:<br />
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''."<br />
<br />
2. Desktops/Personal machines: <br />
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.<br />
<br />
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. <br />
<br />
===Definition===<br />
<br />
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.<br />
<br />
===Requirements===<br />
<br />
'''Communication is a must between all involved.'''<br />
<br />
1. Project Leader - Delegate tasks and project direction.<br />
<br />
2. Packagers - Choosing and handling packages to add to the snapshot repository.<br />
<br />
3. Testers - Testing the stability of packages, logistics, and assistance.<br />
<br />
4. Repository - Will require a server.<br />
<br />
5. (Possibly) Scripting - submit a prototype script below, which can tweak the client (user) pacman.conf to ignorepkg= ''unstablepkg''<br />
<br />
===Project Volunteers===<br />
<br />
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.<br />
<br />
Currently, the project has recruited these members:<br />
<br />
* nagoola - Project Management tasks / Communication. Also programming or package maintenance.<br />
* Nihathrael - Project Management / Programming / Documentation / Homepage / Package maintenance<br />
* rxKaffee - Programming / Provides testing server / Package maintenance<br />
* ibendiben - Coming soon, yet to decide<br />
* Misfit138 - Wrote this page-I am above average with English. Below average at GNU/Linux.<br />
* Basn - Packager<br />
* sixty-four-bit - Packager<br />
* AndyRTR - technical adviser, moderation / coordination if wanted/needed, maybe some packaging for core stuff<br />
* my64<br />
* hussam<br />
<br />
(Please add/remove your name as appropriate and state briefly what you are qualified to offer the project.)<br />
<br />
===Project Status===<br />
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.<br><br />
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.<br />
The methodology section has been updated. <br />
[[User:Nihathrael|Nihathrael]] 10:07, 15 January 2008 (EST)<br />
<br />
===Methodology===<br />
<br />
After some discussion on IRC the following approach has been formed:<br />
<br />
# 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)] <br><br><br />
# Packages will be updated if one of the following happens:<br><br />
## A major package update is released upstream, which has proven to be stable and bug/security fixed over time(~1-4 weeks)<br><br />
##* 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<br />
## A minor package update is released upstream that provides bug or security fixes and is considered stable<br><br><br />
# Critical packages like the kernel will be updated when approved by the maintenance team<br><br />
<br />
Special programs needed:<br />
# 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)<br />
# 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.<br>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)<br />
# 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)<br />
<br />
<br />
As it is early in the project, all are invited to discuss.<br />
<br />
IRC - irc.freenode.net #archlinux-stable<br />
<br />
==Sandbox==<br />
<br />
Crouse's Notes:<br />
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).<br />
<br />
Here is part of my auto-update script I use for my machines.... nothing earth shattering.<br />
I use a cronjob that does 2 things... <br />
<br />
1st downloads a pacman.conf file. Anything that I don't want updated is not updated.<br />
Using the pacman.conf file, an assortment of options present themselves to help keep a system "stable".<br />
Examples:<br />
<br />
IgnorePkg = kernel26<br />
NoUpgrade = etc/lilo.conf boot/grub/menu.lst<br />
HoldPkg = pacman glibc<br />
<br />
<br />
Again, nothing earth shattering, but it does allow me to keep packages that are breaking things, out of the system until proven trustworthy.<br />
<br />
2nd runs an automatic update script (because I'm lazy and don't want to update a dozen plus machines all the time.<br />
Here is the code for that part:<br />
<br />
#Pacman update and logging starts here<br />
echo " " 2>&1 >> /var/log/client.UPDATELOG<br />
echo "#############################################################" 2>&1 >> /var/log/client.UPDATELOG<br />
echo -ne "ARCH CLIENT UPDATE: " 2>&1 >> /var/log/client.UPDATELOG; echo `date +"%D %r"` 2>&1 >> /var/log/client.UPDATELOG<br />
echo "#############################################################" 2>&1 >> /var/log/client.UPDATELOG<br />
# Uncomment here if you want pacman to automatically update this machine<br />
pacman -Syu --noprogressbar --noconfirm 2>&1 >> /var/log/client.UPDATELOG<br />
# If you use lilo, remember to also uncomment the next line<br />
# /sbin/lilo 2>&1 >> /var/log/client.UPDATELOG<br />
<br />
Sorry if this is a bit messy....... feel free to "clean-up" my wiki mess here at the end :)<br />
<br />
<br />
<br />
==Old Entries==<br />
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.<br />
<br />
===Methodology Possibilities===<br />
<br />
Several different methods of achieving the project goal have been proposed-<br />
<br />
They include:<br />
<br />
1. Loosely basing the stable branch on Slackware packaging- expand to clarify, discuss.<br />
a. Follow Slackware-Current<br />
1. Kernel 2.6.23.12<br />
b. Follow Slackware-Stable<br />
1. Kernel 2.6.21<br />
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.<br />
http://distrowatch.com/table.php?distribution=rubix<br />
Review: http://www.tuxmachines.org/node/4699<br />
<br />
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. <br />
<br />
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.<br />
<br />
4. Loosely basing the stable branch on the Frugalware methodology. (Expand to clarify.)<br />
<br />
5. No stable "release" per se, but rather, stable packages.<br />
<br />
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.<br />
''Submit a script here by pasting it below.''<br />
<br />
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.<br />
<br />
===Release-Cycle Ideas===<br />
<br />
<br />
There could be a [core-stable] repository. This repository contains all the packages the normal [core] repo contains. <br><br />
There are 3 possibilities/ideas:<br><br />
<br />
====Version A====<br />
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.<br><br />
Benefits:<br><br />
* Pretty much rock-solid core repository that is very unlikely to break during the 3 months it is used.<br><br />
Disadvantages:<br><br />
* A lot of work is required to back-port security fixes to the rather old packages.<br><br />
* Probably a huge update is required from one release to another.<br><br />
* No upstream improvements/new features are introduced during one release.<br><br />
<br />
====Version B====<br />
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.<br><br />
Benefits:<br><br />
* Stable core repository with very few/none update problems.<br><br />
* 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.<br><br />
* Almost no need to back-port security fixes(only for "problem-packages")<br><br />
Disadvantages:<br><br />
* Higher risk of making the stable repository unstable, by updating packages that cause unknown problems.<br><br />
* 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].<br />
====Version C====<br />
''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.''<br><br />
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). <br />
This is rather advanced and should not be the first thing to try.<br><br />
<br />
All of these are only ideas and need detailed thoughts. So feel free to add/change anything you like.<br />
<br />
<br />
<br />
'''Please feel free to add to or otherwise modify this project page and join the discussion at irc.freenode.net #archlinux-stable'''</div>Sixty-four-bithttps://wiki.archlinux.org/index.php?title=Arch_Linux_Stable&diff=35069Arch Linux Stable2008-01-15T16:43:01Z<p>Sixty-four-bit: /* Methodology */</p>
<hr />
<div>==Arch Linux Stable Branch/Snapshot==<br />
<br />
In reference to the discussion in [http://bbs.archlinux.org/viewtopic.php?id=41764&p=1 this] forum thread, the proposition has been put forth, initially by '''nagoola''', to provide a stable branch or snapshot of the Arch Linux distribution. <br />
<br />
===GOAL===<br />
<br />
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.<br />
<br />
===Concept===<br />
<br />
Why a stable branch? A general consensus has been formed, of the opinion that such a project will be advantageous in several ways:<br />
<br />
1. For the stability of workstations/production machines:<br />
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''."<br />
<br />
2. Desktops/Personal machines: <br />
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.<br />
<br />
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. <br />
<br />
===Definition===<br />
<br />
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.<br />
<br />
===Requirements===<br />
<br />
'''Communication is a must between all involved.'''<br />
<br />
1. Project Leader - Delegate tasks and project direction.<br />
<br />
2. Packagers - Choosing and handling packages to add to the snapshot repository.<br />
<br />
3. Testers - Testing the stability of packages, logistics, and assistance.<br />
<br />
4. Repository - Will require a server.<br />
<br />
5. (Possibly) Scripting - submit a prototype script below, which can tweak the client (user) pacman.conf to ignorepkg= ''unstablepkg''<br />
<br />
===Project Volunteers===<br />
<br />
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.<br />
<br />
Currently, the project has recruited these members:<br />
<br />
* nagoola - Project Management tasks / Communication. Also programming or package maintenance.<br />
* Nihathrael - Project Management / Programming / Documentation / Homepage / Package maintenance<br />
* rxKaffee - Programming / Provides testing server / Package maintenance<br />
* ibendiben - Coming soon, yet to decide<br />
* Misfit138 - Wrote this page-I am above average with English. Below average at GNU/Linux.<br />
* Basn - Packager<br />
* sixty-four-bit - Packager<br />
* AndyRTR - technical adviser, moderation / coordination if wanted/needed, maybe some packaging for core stuff<br />
* my64<br />
* hussam<br />
<br />
(Please add/remove your name as appropriate and state briefly what you are qualified to offer the project.)<br />
<br />
===Project Status===<br />
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.<br><br />
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.<br />
The methodology section has been updated. <br />
[[User:Nihathrael|Nihathrael]] 10:07, 15 January 2008 (EST)<br />
<br />
===Methodology===<br />
<br />
After some discussion on IRC the following approach has been formed:<br />
<br />
# 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)] <br><br />
# Packages will be updated if one of the following happens:<br><br />
## A major package update is released upstream, which has proven to be stable and bug/security fixed over time(~1-4 weeks)<br><br />
##* 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<br />
## A minor package update is released upstream that provides bug or security fixes and is considered stable<br><br />
# Critical packages like the kernel will be updated when approved by the maintenance team<br><br />
<br />
Special programs needed:<br />
# 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)<br />
# 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.<br>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)<br />
# 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)<br />
<br />
<br />
As it is early in the project, all are invited to discuss.<br />
<br />
IRC - irc.freenode.net #archlinux-stable<br />
<br />
==Sandbox==<br />
<br />
Crouse's Notes:<br />
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).<br />
<br />
Here is part of my auto-update script I use for my machines.... nothing earth shattering.<br />
I use a cronjob that does 2 things... <br />
<br />
1st downloads a pacman.conf file. Anything that I don't want updated is not updated.<br />
Using the pacman.conf file, an assortment of options present themselves to help keep a system "stable".<br />
Examples:<br />
<br />
IgnorePkg = kernel26<br />
NoUpgrade = etc/lilo.conf boot/grub/menu.lst<br />
HoldPkg = pacman glibc<br />
<br />
<br />
Again, nothing earth shattering, but it does allow me to keep packages that are breaking things, out of the system until proven trustworthy.<br />
<br />
2nd runs an automatic update script (because I'm lazy and don't want to update a dozen plus machines all the time.<br />
Here is the code for that part:<br />
<br />
#Pacman update and logging starts here<br />
echo " " 2>&1 >> /var/log/client.UPDATELOG<br />
echo "#############################################################" 2>&1 >> /var/log/client.UPDATELOG<br />
echo -ne "ARCH CLIENT UPDATE: " 2>&1 >> /var/log/client.UPDATELOG; echo `date +"%D %r"` 2>&1 >> /var/log/client.UPDATELOG<br />
echo "#############################################################" 2>&1 >> /var/log/client.UPDATELOG<br />
# Uncomment here if you want pacman to automatically update this machine<br />
pacman -Syu --noprogressbar --noconfirm 2>&1 >> /var/log/client.UPDATELOG<br />
# If you use lilo, remember to also uncomment the next line<br />
# /sbin/lilo 2>&1 >> /var/log/client.UPDATELOG<br />
<br />
Sorry if this is a bit messy....... feel free to "clean-up" my wiki mess here at the end :)<br />
<br />
<br />
<br />
==Old Entries==<br />
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.<br />
<br />
===Methodology Possibilities===<br />
<br />
Several different methods of achieving the project goal have been proposed-<br />
<br />
They include:<br />
<br />
1. Loosely basing the stable branch on Slackware packaging- expand to clarify, discuss.<br />
a. Follow Slackware-Current<br />
1. Kernel 2.6.23.12<br />
b. Follow Slackware-Stable<br />
1. Kernel 2.6.21<br />
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.<br />
http://distrowatch.com/table.php?distribution=rubix<br />
Review: http://www.tuxmachines.org/node/4699<br />
<br />
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. <br />
<br />
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.<br />
<br />
4. Loosely basing the stable branch on the Frugalware methodology. (Expand to clarify.)<br />
<br />
5. No stable "release" per se, but rather, stable packages.<br />
<br />
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.<br />
''Submit a script here by pasting it below.''<br />
<br />
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.<br />
<br />
===Release-Cycle Ideas===<br />
<br />
<br />
There could be a [core-stable] repository. This repository contains all the packages the normal [core] repo contains. <br><br />
There are 3 possibilities/ideas:<br><br />
<br />
====Version A====<br />
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.<br><br />
Benefits:<br><br />
* Pretty much rock-solid core repository that is very unlikely to break during the 3 months it is used.<br><br />
Disadvantages:<br><br />
* A lot of work is required to back-port security fixes to the rather old packages.<br><br />
* Probably a huge update is required from one release to another.<br><br />
* No upstream improvements/new features are introduced during one release.<br><br />
<br />
====Version B====<br />
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.<br><br />
Benefits:<br><br />
* Stable core repository with very few/none update problems.<br><br />
* 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.<br><br />
* Almost no need to back-port security fixes(only for "problem-packages")<br><br />
Disadvantages:<br><br />
* Higher risk of making the stable repository unstable, by updating packages that cause unknown problems.<br><br />
* 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].<br />
====Version C====<br />
''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.''<br><br />
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). <br />
This is rather advanced and should not be the first thing to try.<br><br />
<br />
All of these are only ideas and need detailed thoughts. So feel free to add/change anything you like.<br />
<br />
<br />
<br />
'''Please feel free to add to or otherwise modify this project page and join the discussion at irc.freenode.net #archlinux-stable'''</div>Sixty-four-bithttps://wiki.archlinux.org/index.php?title=Arch_Linux_Stable&diff=35068Arch Linux Stable2008-01-15T16:33:50Z<p>Sixty-four-bit: /* Methodology */</p>
<hr />
<div>==Arch Linux Stable Branch/Snapshot==<br />
<br />
In reference to the discussion in [http://bbs.archlinux.org/viewtopic.php?id=41764&p=1 this] forum thread, the proposition has been put forth, initially by '''nagoola''', to provide a stable branch or snapshot of the Arch Linux distribution. <br />
<br />
===GOAL===<br />
<br />
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.<br />
<br />
===Concept===<br />
<br />
Why a stable branch? A general consensus has been formed, of the opinion that such a project will be advantageous in several ways:<br />
<br />
1. For the stability of workstations/production machines:<br />
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''."<br />
<br />
2. Desktops/Personal machines: <br />
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.<br />
<br />
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. <br />
<br />
===Definition===<br />
<br />
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.<br />
<br />
===Requirements===<br />
<br />
'''Communication is a must between all involved.'''<br />
<br />
1. Project Leader - Delegate tasks and project direction.<br />
<br />
2. Packagers - Choosing and handling packages to add to the snapshot repository.<br />
<br />
3. Testers - Testing the stability of packages, logistics, and assistance.<br />
<br />
4. Repository - Will require a server.<br />
<br />
5. (Possibly) Scripting - submit a prototype script below, which can tweak the client (user) pacman.conf to ignorepkg= ''unstablepkg''<br />
<br />
===Project Volunteers===<br />
<br />
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.<br />
<br />
Currently, the project has recruited these members:<br />
<br />
* nagoola - Project Management tasks / Communication. Also programming or package maintenance.<br />
* Nihathrael - Project Management / Programming / Documentation / Homepage / Package maintenance<br />
* rxKaffee - Programming / Provides testing server / Package maintenance<br />
* ibendiben - Coming soon, yet to decide<br />
* Misfit138 - Wrote this page-I am above average with English. Below average at GNU/Linux.<br />
* Basn - Packager<br />
* sixty-four-bit - Packager<br />
* AndyRTR - technical adviser, moderation / coordination if wanted/needed, maybe some packaging for core stuff<br />
* my64<br />
* hussam<br />
<br />
(Please add/remove your name as appropriate and state briefly what you are qualified to offer the project.)<br />
<br />
===Project Status===<br />
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.<br><br />
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.<br />
The methodology section has been updated. <br />
[[User:Nihathrael|Nihathrael]] 10:07, 15 January 2008 (EST)<br />
<br />
===Methodology===<br />
<br />
After some discussion on IRC the following approach has been formed:<br />
<br />
# 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)] <br><br />
# Packages will be updated if one of the following happens:<br><br />
#* A major package update is released upstream, which has proven to be stable and bug/security fixed over time(~1-4 weeks)<br><br />
#*# 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<br />
#* A minor package update is released upstream that provides bug or security fixes and is considered stable<br><br />
# Critical packages like the kernel will be updated when approved by the maintenance team<br><br />
<br />
Special programs needed:<br />
# 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)<br />
# 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.<br>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)<br />
# 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)<br />
<br />
<br />
As it is early in the project, all are invited to discuss.<br />
<br />
IRC - irc.freenode.net #archlinux-stable<br />
<br />
==Sandbox==<br />
<br />
Crouse's Notes:<br />
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).<br />
<br />
Here is part of my auto-update script I use for my machines.... nothing earth shattering.<br />
I use a cronjob that does 2 things... <br />
<br />
1st downloads a pacman.conf file. Anything that I don't want updated is not updated.<br />
Using the pacman.conf file, an assortment of options present themselves to help keep a system "stable".<br />
Examples:<br />
<br />
IgnorePkg = kernel26<br />
NoUpgrade = etc/lilo.conf boot/grub/menu.lst<br />
HoldPkg = pacman glibc<br />
<br />
<br />
Again, nothing earth shattering, but it does allow me to keep packages that are breaking things, out of the system until proven trustworthy.<br />
<br />
2nd runs an automatic update script (because I'm lazy and don't want to update a dozen plus machines all the time.<br />
Here is the code for that part:<br />
<br />
#Pacman update and logging starts here<br />
echo " " 2>&1 >> /var/log/client.UPDATELOG<br />
echo "#############################################################" 2>&1 >> /var/log/client.UPDATELOG<br />
echo -ne "ARCH CLIENT UPDATE: " 2>&1 >> /var/log/client.UPDATELOG; echo `date +"%D %r"` 2>&1 >> /var/log/client.UPDATELOG<br />
echo "#############################################################" 2>&1 >> /var/log/client.UPDATELOG<br />
# Uncomment here if you want pacman to automatically update this machine<br />
pacman -Syu --noprogressbar --noconfirm 2>&1 >> /var/log/client.UPDATELOG<br />
# If you use lilo, remember to also uncomment the next line<br />
# /sbin/lilo 2>&1 >> /var/log/client.UPDATELOG<br />
<br />
Sorry if this is a bit messy....... feel free to "clean-up" my wiki mess here at the end :)<br />
<br />
<br />
<br />
==Old Entries==<br />
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.<br />
<br />
===Methodology Possibilities===<br />
<br />
Several different methods of achieving the project goal have been proposed-<br />
<br />
They include:<br />
<br />
1. Loosely basing the stable branch on Slackware packaging- expand to clarify, discuss.<br />
a. Follow Slackware-Current<br />
1. Kernel 2.6.23.12<br />
b. Follow Slackware-Stable<br />
1. Kernel 2.6.21<br />
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.<br />
http://distrowatch.com/table.php?distribution=rubix<br />
Review: http://www.tuxmachines.org/node/4699<br />
<br />
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. <br />
<br />
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.<br />
<br />
4. Loosely basing the stable branch on the Frugalware methodology. (Expand to clarify.)<br />
<br />
5. No stable "release" per se, but rather, stable packages.<br />
<br />
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.<br />
''Submit a script here by pasting it below.''<br />
<br />
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.<br />
<br />
===Release-Cycle Ideas===<br />
<br />
<br />
There could be a [core-stable] repository. This repository contains all the packages the normal [core] repo contains. <br><br />
There are 3 possibilities/ideas:<br><br />
<br />
====Version A====<br />
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.<br><br />
Benefits:<br><br />
* Pretty much rock-solid core repository that is very unlikely to break during the 3 months it is used.<br><br />
Disadvantages:<br><br />
* A lot of work is required to back-port security fixes to the rather old packages.<br><br />
* Probably a huge update is required from one release to another.<br><br />
* No upstream improvements/new features are introduced during one release.<br><br />
<br />
====Version B====<br />
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.<br><br />
Benefits:<br><br />
* Stable core repository with very few/none update problems.<br><br />
* 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.<br><br />
* Almost no need to back-port security fixes(only for "problem-packages")<br><br />
Disadvantages:<br><br />
* Higher risk of making the stable repository unstable, by updating packages that cause unknown problems.<br><br />
* 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].<br />
====Version C====<br />
''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.''<br><br />
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). <br />
This is rather advanced and should not be the first thing to try.<br><br />
<br />
All of these are only ideas and need detailed thoughts. So feel free to add/change anything you like.<br />
<br />
<br />
<br />
'''Please feel free to add to or otherwise modify this project page and join the discussion at irc.freenode.net #archlinux-stable'''</div>Sixty-four-bit