Re: Version bump policies and beta packages in stable branch

Hi,
There seem to be two aspects to this problem. One is how to manage it=20
from the perspective of the Package management System. The other is how=20
to manage it from the perspective of the Distribution.

1) Package Management System.

The best that the PMS can achieve is to implement a system that is=20
ultimately flexible and infinitely easy to use with respect to Package=20
Selection and Control. These two ideals (flexible and easy) are usually=20
mutually exclusive to one degree or another however if the underlaying=20
engine is flexible then the UI that gets bolted onto the engine can=20
implement an easy subset of all that is achievable.
This thread in the forums is useful I think for a nice flexible approach=20
to package selection.

http://forums.zynot.org/viewtopic.php?t=3D225

nall's proposed approach provides for an extremely flexible way to=20
prioritise packages (co)existing in multiple trees. Trees are=20
essentially distributions and are only called trees for historical=20
reasons. They do not need to be tree shaped any more although they may=20
be displayed in a hierarchy at the discretion of the UI.

2) Distribution.

This is allways the make or breake of a distribution as it determines:

a) How the user experiences the distro: are all the packages up to date=20
enough?
b) How easy the distro is to maintain: how many interdependent packages=20
are required to change to form a new stable?
c) Can the distro integrate with other distributed software not=20
affiliated with the distro? That is if I want to supply some audio apps=20
as a third party to anyone running a Zynot System using Xeta can people=20
use my mini-distro at the same time?

Solutions...(?)

a) Being source based (or at least source capable) allows for the most=20
fine grained upgrade progress achievable.
b) Maybe a more structured approach to the distro as opposed the the=20
more traditional monolithic model currently used by most. By this I mean=20
rather than having stable/unstable woody/metalic etc... Why not utilise=20
the power of the multiple trees enabled by the underlaying PMS and break=20
the distro down into components. For example:

RH style system
----------------

zynot-stable
zynot-testing
zynot-unstable

Componentised system
------------------------

zynot-base(-stable|-unstable)
zynot-audio(-stable|-unstable)
zynot-video(-stable|-unstable)
zynot-inet(-stable|-unstable)
zynot-gnome(-stable|-unstable)
zynot-kde(-stable|-unstable)
zynot-dev(-stable|-unstable)

Now I have to say I really don't know if breaking the distribution down=20
into sub-distributions like this will help or hinder the process of=20
building a stable platform but it's an idea that people might want to=20
think about.

c) A third party developer could be easily integrated into the above=20
scenario:

mikado-audio(-stable|-unstable) // Either an alternative to or a=20
suppliment of zynot-audio from mikado.
borland-dev // Borland's official development tools.

- Galik


Frantz Dhin wrote:

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