Hi folks I tried to find a solution for the update problem. Currently I have 3 kernels, 2.6.16-16, 2.6.16-17 and 2.6.17-6 and each of them needs another hypervisor. As it is the goal of Debian to not break on updates completely, I propose the following change: * Introduce xen-common source which provides xen-utils-common binary packages. This package provides a dispatcher for the installed xen-utils packages. * xen-3.0 produces xen-hypervisor-$version-$abi-$flavour and xen-utils-$version-$abi. $version is the upstreamversion like 3.0.2 or 3.0-unstable, $abi describes the dom0 interface. * xen-hypervisor depends on the correct xen-utils. * The linux package produces another binary xen-linux-system-$kernelversion which depends on the correct linux-image and xen-hypervisor packages. It also provides some information to update-grub, which xen image to use for the given kernel. This way I can install a new kernel and have real chances that it will not break unconditionaly. Bastian -- Death, when unnecessary, is a tragic thing. -- Flint, "Requiem for Methuselah", stardate 5843.7 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature Url : http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20060818/07b6474f/attachment.pgp
On Fri, Aug 18, 2006 at 11:13:14PM +0200, Bastian Blank wrote: Hi Bastian,> I tried to find a solution for the update problem. Currently I have 3 > kernels, 2.6.16-16, 2.6.16-17 and 2.6.17-6 and each of them needs > another hypervisor. As it is the goal of Debian to not break on updates > completely, I propose the following change: > > * Introduce xen-common source which provides xen-utils-common binary packages. > This package provides a dispatcher for the installed xen-utils > packages. > * xen-3.0 produces xen-hypervisor-$version-$abi-$flavour and > xen-utils-$version-$abi. $version is the upstreamversion like 3.0.2 or > 3.0-unstable, $abi describes the dom0 interface. > * xen-hypervisor depends on the correct xen-utils. > * The linux package produces another binary > xen-linux-system-$kernelversion which depends on the correct > linux-image and xen-hypervisor packages. It also provides some > information to update-grub, which xen image to use for the given > kernel. > > This way I can install a new kernel and have real chances that it will > not break unconditionaly.I don't have any objection. It seems that there is no more compatibility between version, that's a shame. But in the meantime, your solution seems to be good, so I'll say go ahead with it. Cheers, -- Julien Danjou .''`. Debian Developer : :' : http://julien.danjou.info `. `' http://people.debian.org/~acid `- 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20060819/008946c0/attachment.pgp
On Fri, Aug 18, 2006 at 11:13:14PM +0200, Bastian Blank wrote:> * Introduce xen-common source which provides xen-utils-common binary packages. > This package provides a dispatcher for the installed xen-utils > packages. > * xen-3.0 produces xen-hypervisor-$version-$abi-$flavour and > xen-utils-$version-$abi. $version is the upstreamversion like 3.0.2 or > 3.0-unstable, $abi describes the dom0 interface. > * xen-hypervisor depends on the correct xen-utils. > * The linux package produces another binary > xen-linux-system-$kernelversion which depends on the correct > linux-image and xen-hypervisor packages. It also provides some > information to update-grub, which xen image to use for the given > kernel.* Change versioning to match upstream versions: - 3.0.2-3+hg9762 - 3.0-unstable+hg11205 * Only use short version for xen-ioemu. A wrong version does not break the boot and it is not easy possible to pull in the last version without dependency. Bastian -- I'm a soldier, not a diplomat. I can only tell the truth. -- Kirk, "Errand of Mercy", stardate 3198.9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature Url : http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20060821/b71ae357/attachment.pgp
On Fri, Aug 18, 2006 at 11:13:14PM +0200, Bastian Blank wrote:> This way I can install a new kernel and have real chances that it will > not break unconditionaly.The situation changed a little bit in between. Keir Fraser wrote in changeset 11257: | From here on we hope to maintain dom0 kernel compatibility. This | promise is not extended to tool compatibility beyond the existing | guarantee that compatibility will not be broken within a three-level | stable release [3.0.2, 3.0.3, etc.]. So we may rethink that and go back to the old naming scheme. But I propose to do that not and maintain that for tool compatibility. Also they may break the dom0 kernel compatibility also and we adress this now. Bastian -- It is more rational to sacrifice one life than six. -- Spock, "The Galileo Seven", stardate 2822.3 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature Url : http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20060831/00092d71/attachment.pgp
On Thu, Aug 31, 2006 at 09:20:43AM +0200, Bastian Blank wrote: Hi,> | From here on we hope to maintain dom0 kernel compatibility. This > | promise is not extended to tool compatibility beyond the existing > | guarantee that compatibility will not be broken within a three-level > | stable release [3.0.2, 3.0.3, etc.]. > > So we may rethink that and go back to the old naming scheme. But I > propose to do that not and maintain that for tool compatibility. Also > they may break the dom0 kernel compatibility also and we adress this > now. >Since you did all this work to change and the new situation addresses the compatibility problem we might leave it as is for now, and maybe go back after etch is released and this new compatibility is there for a little longer. The only real problem I see with the new scheme is longer times for the uploads, as all the name changes will cause the packages to be held in NEW... :/ The old scheme, provided compatibility is there, grants us quicker update times! What do people think? Guido