[Pkg-xen-devel] Some words on my debian files...
ralph at debianbase.de
Thu Feb 16 13:28:36 UTC 2006
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: 220.127.116.11-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
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
- 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... :)
More information about the Pkg-xen-devel