mike cloaked wrote:
> So how did Arch Linux cope with that particular set of changes? I
> suppose Arch Linux collapsed never to recover? I think not!
There are 2 ways rolling release distros handle this kind of transition:
a) They just push it. That leaves you with e.g. your desktop being upgraded
from KDE 3 to KDE 4 overnight! A very nasty surprise, considering that some
reconfiguration is required for the workspace, and that some applications
got rewritten with feature regressions. IMHO such a change is totally
unsuitable to be pushed as a mandatory update.
b) They push it with a new name and force you to migrate by hand. This sucks
in several ways:
* The user has to follow a migration manual to manually replace the old
packages with the new ones.
* Either the old and new versions conflict with each other, which is not a
nice packaging practice (and makes upgrading more difficult for the user),
or they are parallel-installable, which usually implies that migration of
configuration settings is manual, too.
* The developers have to maintain both the old and new version in parallel
for quite some time, and application packagers depending on the changed
lower-level package have to support both setups, usually in the SAME package
(which is a nightmare, compared to being able to have separate branches for
the old and new setup like the Fedora 8 and 9 branches in our case), or also
duplicate their package into old and new version, with the same issues.
* The users ultimately end up with an unsupported configuration (when the
developers finally discontinue the old version) if they don't migrate
manually. So this has the same drawbacks as a release-based model, except
that (i) you have to read and follow a page of instructions to get the new
packages for a rolling release distro using approach b) instead of just
upgrading to the new release and (ii) the EOL for the old packages is
usually much less predictable than the EOL for Fedora releases.
>> Where we can get to is "semi-rolling", i.e. push version upgrades as
>> updates to stable releases wherever safe, but not the disruptive changes.
>
> That is actually more like rolling release- except that there is no
> EOL in a rolling release model! Periodically there are new install or
> live isos but an installed system just keeps getting new stufff!
But that includes new stuff which BREAKS things! The point of the semi-
rolling model is that it does NOT include the stuff which breaks things.
> In fact,
>> that's what we did before the new stable update policies which I still
>> believe are NOT what the majority wants and need to be repealed (and be
>> replaced by a policy which ensures that packages will be consistently
>> upgraded, without the "I maintain package XYZ and I don't believe in
>> version upgrades for stable releases, so there will be none" nonsense).
>> Want the disruptive changes? Then yum upgrade to the latest release.
>> Otherwise you only get the safe ones.
>
> Yup big updates that may sometimes need manual intervention to change
> configs - an example is dovecot when it changed to v2 - the configs
> changed. Not insurmountable - but at least without changing
> everything else at the same time it is a lot easier to deal with,
> surely?
No, quite the opposite (because it means you get bothered with such changes
many times, at potentially inappropriate times, with no way to opt out), see
my reply to Gene ("Genes MailLists").
>> But a fully rolling release just cannot work (and this is also why all
>> those "just use Rawhide if you want the latest", "usable Rawhide" etc.
>> suggestions are fundamentally flawed). Yes, there are distros doing this,
>> but they all have one thing in common: doing a migration like the KDE 4
>> migration is a big PITA in them.
>
> Again - how on earth did Arch Linux survive it
In a suboptimal way.
> and did the arch users desert that distro in large numbers as a result?
I'm sure some of them did (and moved to release-based distros, which all
handled the transition sanely :-) ), the remaining ones are probably used to
stuff being broken, just like Rawhide users. That doesn't mean it's a model
which works for production machines.
Kevin Kofler
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
