Hello all,
So we have this problem that I’d like to put up here
for discussion. It has been boggling my mind for quite a while.
The problem:
Best summarized using the Gentoo distribution as an example.
In Gentoo you basically have a choice of 2 distributions. A stable and an
unstable branch. Some would like you to believe that a choice between a wealth
of package versions exists in this “meta distribution”, but in
reality you are limited to these two package sets.
If you type “emerge mysql” on the command line
in Gentoo today you get version 4.0.16 if you are running the stable branch, and
4.0.17 if you are running unstable. Now question is: Where are v4.1 and v5.0
versions of MySQL in the Portage
tree? Answer: They are not there. So when will they be there and when will
stable or unstable versions suddenly prompt you to upgrade? Good question that
only the package maintainer can answer.
Now the problem in performing a MySQL v4.0 to v4.1 upgrade
will be that some upgrading will need to be done on the database tables
themselves. In other words a 4.0 database is most likely not compatible with a
4.1 database. For a database of a reasonable size this is no trivial operation.
It will require planning, testing and a good chunk of human resource time. It
is an operation that needs to be carried out at a time of convenience.
For a while Gentoo was running with MySQL 3.23 in the stable
branch and 4.0.x in the unstable branch. One day the package maintainer decided
that now it was time to “move v4.0.x to stable” and announced this
on gentoo-dev mailing list, and so it became.
I hope everyone is now beginning to see the problem. What
happens when it is time to move 4.1 into unstable or stable? How many oopses
will we hear the users say? How much annoyance is it going to cause when a
package manager constantly offers you a package upgrade that you don’t
have time for or may not even want for years to come? And what happens when you
in 2 years badly need to restore your MySQL 4.0 system fast and smooth. –
Is the ebuild for the exact version you need still guaranteed to be there and
accessible for you?
A workaround could be to split it into 3 separate packages
named such as these. The naming is taken from mysql.com.
Mysql-production-release (Currently 4.0.x)
Mysql-alpha-release (Currently 4.1.x)
Mysql-development-tree (Currently 5.0.x)
But really that is just delaying and making a half solution
to the problem, because there will be a day where v4.1 will be recommended as
the current “production release”.
I have here used Gentoo and MySQL as an example. Not
intended as flaming, but to illustrate a problem of a more general nature.
Think of Apache 1.3.x and 2.0.x which are both used in production and will be
for a long time still. Think of the Gimp (1.2.x) and the beta version of it
(1.3.x) which also get version incremented independently in both branches.
In Gentoo it was for a while as such that if you were
running stable you got Gimp 1.2 and if you were running unstable you got Gimp
1.3 handed to you. IMHO you should have the choice of both no matter what OS
branch you run, but here obviously separating into 2 packages and naming them
gimp and gimp-beta would suffice.
To conclude this I suggest a general policy for the trees we
develop to provide as much choice as possible when it comes to running beta
packages in a so-called ‘stable’ release. We should, especially for
desktop applications, avoid forcing a whole set or branch of packages on a user
who in all innocence is curious about what the beta release of Gimp is like.
It would all-in-all be a more effective use of having a
stable vs an unstable branch if, for instance, gimp 1.2.4 and gimp-beta 1.3.22
were placed in stable, while gimp 1.2.5 and gimp-beta 1.2.23 were in testing
stage. I suggest making this a general principle as long as the technical
implications do not become too much of a burden. I realize that running a beta
of an application could force an upgrade of a bunch of libs which again could
break a lot of things. I imagine a beta of Evolution for instance would have
this trait, so a policy like this of course has to be kept within reason.
Furthermore, not neglecting the problem with a package such
as MySQL, I am still in search for solutions and mechanisms and policies to
handle this exact problem. Do not forget that we seek to create a data center
worthy distribution. The demands for such a distribution is that it can be
installed on large machinery and clusters and be able to run the next 15 years
with 99.999% uptime. Take this into account, but I am eager to hear comments
and proposals for solutions…
Best Regards
Frantz Dhin
CEO, Zynot Foundation
RSS Feed