[Pkg-xen-devel] Some words on my debian files...

[Ralph Passgang]

Hi,

since the repo is up and the debian files from "xen3.0.1-0tha2" are uploaded I 
want to say some words about my work. This could help to understand what I 
have done and makes it easier to understand what needs to be done to have it 
in a good shape for debian.

- I have written down (more or less all) changes to debian/changelog, so 
reading it might help understanding what is working how and why.

- I haven't patched the upstream, so my debian files should work on xen3.0.1 + 
all testing changesets after the 3.0.1 release. For "unstable" there are some 
minor things that needs to be changed (for example kernel version, there are 
more files to install, ...).

- with xen3 there is also a pae support for systems with more than 4gb ram, 
which needs to be configured at compile time. But because many (old) system 
doesn't support pae at all we need to have the default xen packages build 
without pae support.

At the moment there is a parameter in debian/rules to enable/disable pae, but 
this isn't really a solution for debian, instead we need to find another way. 

I would think of the following:

We could compile all stuff without thje pae flag and then (if arch=i386) 
compile just the hypervisor again with pae support and package that with 
another name, for example: "xen-pae". If we would make it this way, we would 
only have one source package for i386, i386+pae and amd64.

- the upstream Makefile target for creating a kernel-patch is broken, so I 
have some commands in the debian/rules file for creating a working 
kernel-patch-xen file anyways... I hope this is not really needed in future 
versions, but for the moment nobody seems to fix that in upstream.

- the dh_kpatches doesn't produce patches for kernels if an extraversion is 
set. So I had to remove the extraversion before the dh_kpatches call. This is 
quite a dirty hack (and not working for xen unstable for example), but afaik 
needed in the moment. I don't know if this would be ok in debian or if we 
need another solution.

the resulting linux-patch-xen package required (at the moment) a clean 2.6.12 
kernel source and will convert it to: 2.6.12.6-xen. But the version will not 
be in the .config file (because I had to strip the extraversion as I said). 
For me this was not a problem, because using the make-kpkg option: 
"append-to-version .6-xen" added the missing extraversion again, but in 
general this isn't ideal. But I don't know how to solve it, maybe we should 
ask the maintainers of dh_kpatches.

- My package doesn't have a kernel source included, even if it's needed for 
building the kernel-patch. Originally Adam used the debian kernel-source and 
removed all debian specific patches, but he also noticed that this isn't a 
good solution, because not all kernel-source versions are available in all 
debian distributions and might disappear in future (and then will brake our 
packages).

My solution is to just ignore that and use the upstream method to fetch a 
vanilla kernel-source from www.kernel.org. Adam said (some time ago) on the 
xen ml, that he also will fetch the sources with wget in future versions, but 
then he never uploaded any new packages after that posting.

If fetching external stuff is a problem with debian's policy, even if the 
external files are the kernel sources and of course open source and even if 
this is how upstream handles it, then we might want to include the kernel 
source as .tar.bz2 in the xen upstream directory, because then xen's makefile 
will use that archive and will not fetch it anymore. But this will blow our 
source package a lot! But on the other hand will safe traffic on 
www.kernel.org.

- My packages are also building & working on amd64 but I am not sure if I made 
it correct. I noticed that xen wants to install libraries in /lib64, but 
debian expects them to be in /lib (because /lib64 is just a symlink to /lib). 
I managed that by having the libraries moved to the correct location on amd64 
hosts before the files gets packaged (see debian/rules), but I guess it would 
be better to tell the correct library path at configure/compile-time and not 
using a hook like this..

hmm, I guess that are the main facts... :)

--Ralph