Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

distributions



David Rosenstrauch wrote:
> Jerry Feldman wrote:
>> ...a continuous upgrade (well Gentoo does this to some extent).
> 
> Arch Linux works this way as well.  They operate with what they call a 
> "rolling release" system.  You basically just install Arch once, and 
> never "upgrade" to a new "version" ever again.
...
> ...I often find myself scratching my head in a combination of 
> amusement and disbelief at the various mailing list posts I read about 
> problems people run into when upgrading to the latest version of Fedora, 
> Ubuntu, etc.

Do you compile packages locally with Arch as you do with Gentoo?

If not, then how does it handle library version skew?


> In practice, you just keep upgrading individual packages.  Sometimes 
> when the upgrades are major (e.g., when upgrading kernel, xorg, kde, 
> gnome, etc.) you run into some headaches, but mostly not. 

That sounds pretty close to Ubuntu. Unlike Debian, they do upgrade some
packages between releases (Debian stable only provides security
updates), and new releases pretty much always include a newer kernel, X,
GNOME, etc.


> And at least you don't run into a whole bunch of package upgrade
> headaches all at once, as you would when upgrading to a new version
> of a distro.

I run into distribution upgrade headaches with Debian and Ubuntu, though
despite many dozens of packages being updated simultaneously, typically
only one or two poses a problem. For the most part a distribution
upgrade is just a bit inconvenient due to the time required to merge
local config changes into the stock config files.


In theory, with a distribution like Arch, if any package can be at any
version, that creates a pretty huge set of permutations such that no two
Arch systems will be anywhere close to identical. So if something
breaks, what are the chances that someone else is running the same set
of packages you are?

It sounds like in practice this hasn't been a problem, but one of the
big points to having a defined release is that it can be tested as a whole.

Perhaps this works for Arch because the majority of users keep all their
packages updated to the latest versions, and that rolling target is what
package maintainers test against. Of course that starts to fall apart if
you have a lot of package maintainers all working independently.

 -Tom

-- 
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/






BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org