[Pkg-xen-devel] Proposed changes

[Bastian Blank]

On Tue, Feb 28, 2006 at 03:49:47PM -0800, Jeremy T. Bouse [c] wrote:
> Bastian Blank wrote:
> >>- Overwrites xen binary package without an upgrade procedure.
> >Remove the xen binary package.
>     As I recall and looking back quickly at the r63 trunk this xen
> package is merely a package with dependencies to the utils and
> hypervisor. Are you suggesting doing away with this sort of
> transitional/meta-package completely? Do you have another way to
> accomplish this easier?

This is no meta-package. It is the package which contains the hypervisor
for the xen 2 packages. As it is not possible to provide an upgrade
procedure, this can't be changed.

> >>- The installed xen image lacks a version in there name and another
> >>  identification, which type it is.
> >- Rename xen-hypervisor to xen-hypervisor-$(MAJOR)-i386/-amd64
> >- Rename xen-hypervisor-pae to xen-hypervisor-$(MAJOR)-i386-pae
>     We'll have to work to modify the build for the non-PAE version to
> accomodate the -i386 and -amd64 version of the package unless we simply
> go with xen-hypervisor-$(MAJOR) as the package itself will identify the
> arch as i386 or amd64 already.

No, it does not. With the implementation of multiarch, there will be
only one arch and the two packages are not replacable.

> >- Only install the bare image (xen.gz), not the unstripped and
> >  uncompressed files. This files are only usefull for debugging and
> >  makes the package large without gain.
>     This makes sense. Do we want to provide the debugging files in a
> -dbg or -debug package to make them available if needed but not necessary?

No. Only a symbol file like the kernels will make sense.

> >- Remove libxen*. xen don't have proper sonames and managed to have
> >  different interfaces in 3.0 and unstable but the same soname. Maybe
> >  even remove the version from the soname.
> >- Move libs to /usr/lib/xen-$(MAJOR) and add proper rpaths.
>     If we remove the libxen* packages built, then where should we place
> these files? Within the xen-utils-<version> or with the hypervisor?

They belongs to the utils. The hypervisor is unrelated. (You don't need
the utils to run the hypervisor)

> >- Implement xen-common to allow more than one version installed at the
> >  same time and detect the neccesary version on runtime.
>     This xen-common might also be able to handle the meta-package if we
> wanted as it could have the dependencies on a hypervisor and utils
> packages available. Conversely the hypervisor and/or utils could depend
> on it being available for configuration.

Bah, don't invent recursive dependencies.

Bastian

-- 
Without followers, evil cannot spread.
		-- Spock, "And The Children Shall Lead", stardate 5029.5
-------------- 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/20060301/ed1c432b/attachment.pgp