[Pkg-xen-devel] Proposed changes [u]

[Jeremy T. Bouse [c]]

Bastian,

    If you hadn't already noticed I've added you to the Alioth project
already. Further commenting inline.

Bastian Blank wrote:

>Hi folks
>
>This is the list of changes I'll propose.
>
>On Tue, Feb 28, 2006 at 10:15:39AM +0100, 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?

>>- Uses xen as source name, which at least the kernel team knows that
>>  this may easily break if more than one version is needed.
>>    
>>
>
>Move /trunk/debian to /trunk/xen-3.0/debian and add
>/trunk/xen-unstable/debian.
>
>  
>
    This sounds quiet reasonable and I'll go ahead and move our current
trunk/debian to trunk/xen-3.0/debian and commit this afternoon. I can
definately see the logic in this directory tree structure going forward.

>>- All core binary packages lacks the version in the name.
>>    
>>
>
>Rename xen-utils to xen-utils-$(MAJOR). (MAJOR is 3.0 or unstable in
>this case)
>
>  
>
    This also makes sense and was something we'd need to address as well
with two paths (stable major and unstable). I will update debian/control
as well prior to committing today.

>>- 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. I did include a "Provides:
xen-hypervisor-3.0" to it as well as xen-hypervisor-3.0-i386-pae and
changed xen-utils-3.0 to Depend on "xen-hypervisor-3.0" which should
ensure a 3.0 hypervisor is available. If we just named the non-PAE
version as xen-hypervisor-$(MAJOR) as the arch would be in the package
name already, we could likewise call the PAE version
xen-hypervisor-3.0-pae to shorten the name as well. Your thoughts?

>Further changes:
>- 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?

>I have my own tree with the points above implemented:
>https://lophos.multibuild.org/svn/xen/trunk/
>
>Unimplemented changes:
>- 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? If
we place them in either it would be necessary to use the version'd
/usr/lib directory or else we have to deal with handling the conflicts
between multiple versions being installed. Both make good sense and
would improve things in the long run.

>Maybe:
>- Implement xen-common to allow more than one version installed at the
>  same time and detect the neccesary version on runtime.
>
>Bastian
>  
>
    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.

    Still may need to make some clean-ups to this commit when going to
build but trying to get it committed so we can start working from something.

    Regards,
    Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20060228/0a73704a/signature-0001.pgp