3

In my understanding of linux distributions, you get notified of updates, then by a simple click or with a bunch of commands you can install them. These may be patches or minor version updates of software you installed previously. For example, the distribution may suggest to upgrade firefox version 23 to firefox version 24 (bad example this is not a minor release but you get the idea). After a few months, though, the system asks you to do an upgrade : you're updating the system itself, not the software packages you have installed.

Why can't the system itself be updated the same way as other software packages, via small, continuous updates ?

What solution do rolling releases use to solve this problem ?

3
  • 2
    en.wikipedia.org/wiki/Rolling_release pretty much covers it...
    – jasonwryan
    Oct 23 '13 at 17:53
  • There was some good discussions on rolling releases in this U&L Q&A from a while back, titled: What is the prefered way of updating all software in a Fedora installation?. I provided one of the answers.
    – slm
    Oct 23 '13 at 17:58
  • Why can't the system itself be updated the same way as other software packages, via small, continuous updates ? It's a tradeoff: bleeding edge (rolling release) vs unchanging known quantity (stable distro version). As in any tradeoff, there can be middle ground solutions: Gentoo stable vs unstable, Debian stable/testing/unstable, ...
    – ninjalj
    Oct 25 '13 at 14:50
6

Why can't the system itself be updated the same way as other software packages, via small, continuous updates ?

It could, as you notice some distros do work that way. The process of upgrading essentially is a set of updates; your distinction between "updating the system itself" and "not the software packages you have installed" is a little imprecise since the system is just software packages you have installed. Various distros may have some explicit criteria that applies only to upgrades, but I don't think that's the reason for using this method. I don't think there is any specific technical reason at all for using version upgrades, and I doubt it would require much for a traditional versioning distro to convert to rolling release.

I think the primary reason is compartmentalization. Version 2 of something may entail significant changes over version 1 that can't just be done with a series of reversible tweaks. So while you are working on version 2, there may be a need to continue maintenance on version 1 that doesn't apply to 2. Pretty much all actual software is done this way. AFAIK, it is just software distributions which use a rolling release model.

Also, users appreciate having a previous version to fall back on if V.2 turns out to be a fiasco initially, a logic that certainly applies to linux distros.

What solution do rolling releases use to solve this problem ?

Well, they use versioning with the packages. This is fine since, as mentioned, the system is nothing but packages. There isn't anything that's installed that isn't part of a package, so modifying the system is just a matter of collectively changing some packages.

With versioned distros, packages actually have two versions associated with them, the package version and the distro version. E.g. you'll find a whatever.1.2.3 package for several concurrent versions of the distro. I image this provides a fair bit of flexibility WRT what I said about "significant changes" between distro releases. Whatever1.2.3 may be from the same upstream (original) source, but configured differently in distro release 2 to reflect substantial architectural changes over release 1.

2
  • No possible forks eh? Actually, it would also be sloppy to say that it applies to gentoo...deleted.
    – goldilocks
    Oct 23 '13 at 18:12
  • 1
    note that Arch isn't derived from anything. it was written from scratch.
    – strugee
    Oct 23 '13 at 18:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.