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

[Guido Trotter]

On Thu, Feb 16, 2006 at 02:28:36PM +0100, Ralph Passgang wrote:

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.
> 

Thanks!

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

That's great! ;)

> - 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.
> 

Ok, agreed... Also, I recall from the xen mailing lists that they disabled PAE
by default not because of a concern about older machines, but because they
thought it wasn't ready yet! Shouldn't we perhaps write that it's experimental
and to use the normal version if possible (that is: if one has less than 4gb of
ram) ;)

> - 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.
> 

Yeah, probably this could count as a bug in dh_kpatches which was written
probably before the "stable kernel" hera, when extraversion wasn't used at
all... 

> - 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.
> 

I can't find in the debian policy any rule against downloading external code...
And since we're downloading a kernel source there shouldn't be an issue with
that... We might want to check the md5sum or the gpg signature of the archive,
after the downlpad, just to be conservative, though!

> - 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..
> 

Well, it's just because other distros are mixed 32-64 while debian is pure 64
(and one can build a 32bit chroot, if he wants too...) so lib64 isn't needed...

I think we can apply this patch with dpatch before starting the compilation, and
that should solve most of the issue! I don't have an amd64 handy to try it, though!

diff -ru xen-3.0.1.orig/Config.mk xen-3.0.1/Config.mk
--- xen-3.0.1.orig/Config.mk    2006-02-16 16:19:44.000000000 +0100
+++ xen-3.0.1/Config.mk 2006-02-16 16:20:10.000000000 +0100
@@ -27,11 +27,7 @@
 INSTALL_DATA = $(INSTALL) -m0644
 INSTALL_PROG = $(INSTALL) -m0755

-ifeq ($(XEN_TARGET_ARCH),x86_64)
-LIBDIR = lib64
-else
 LIBDIR = lib
-endif

 ifneq ($(EXTRA_PREFIX),)
 EXTRA_INCLUDES += $(EXTRA_PREFIX)/include

Ciao,

Guido

PS there are a couple more files in the source which references lib64, we might
have to dpatch those too... Or see if we can make the patch so that it only
affects debian, and then can be accepted upstream too...