Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Simo Sorce]

On Sat, 2012-11-03 at 00:18 +0100, drago01 wrote:
> On Sat, Nov 3, 2012 at 12:04 AM, Adam Williamson <awilliam at redhat.com> wrote:
> > [...]
> > * Upgrading every year, with an unreliable upgrade process, is not
> > something you have to do with a proper stable OS
> 
> I am not sure why you call it unreliable ... I *never* reinstall
> unless I really had to (moving one installation from i386 to x86_64).

On one machine I did upgrade from i386 -> x86_64 just for fun.
Sure I had to drop in single user 3-4 times and manually install some
rpm but eventually I got it done (it was a VM ;)

> Otherwise I always upgrade using either anaconda back in the days and
> then preupgrade.
> 
> There is some weird attitude that "upgrades don't work anyway people
> should just reinstall". Not only is a reinstall a lot more work it is
> just not something you could ask from a user to do every 6-12 months.

it would be nice to squash 2 release cycles and use the gained time to
make a better upgrade process imo.

> Technically there is no difference between an upgrade and package
> updates just the package set is larger, it just makes dealing with
> stuff like usrmove easier. If an update from foo-1.0 to foo-2.0 breaks
> the whole system it will regardless whether you upgrade from FN-1 to
> FN or doing a "yum update" in a rolling release.

+1

however there is a difference, sometime many little changes over time
can run much smoother than one big change at once where you go tfrom pkg
release N-10 to N

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York