Hi Stefano

I was encouraged by Bruce to forward my patches upstream to make Xen sources
buildable from debian makefile debian/rules and for debian based target
systems.

I tried to make my 3 of 4 (5) patches to xen40-testing.hg as non intrusive
as possible

- backport-StdGNU.mk.diff  (from xen-devel, already here)
- debian-sysconfig-default.diff  (conditional Makefile expansion)
- tools-blktap2-libs.patch   (from debian Xen-4.0 sources)
- debian-python-2.6.diff  (conditional Makefile expansion)
- debian-stubdom.Makefile.diff  (conditional Makefile expansion)

Config.mk gets patched with the line:

DEBIANBASE ?= \
$(shell test ! -d /etc/sysconfig && test -d /etc/default && echo y || echo
n)

... and three other patches depend on it.

tools-blktap2-libs.patch is non conditional but it seems quite reasonable
(only moves FLAGS definitions closer to the sources requiring them) and
comes from a respected source.

If these are applied Xen sources build without errors from superior debian
build makefile
"debian/rules", bringing updating Xen through debian package management.

See for example of debian packager:
http://virtualusr.wordpress.com/2011/01/03/xen-4-0-packager-for-ubuntu/

Original 4.0.1 source builds on Ubuntu Lenny 10.04 with
  make dist
and produces similar result as pached 4.0.1 source builds with
  make dist DEBIANBASE=n

Patched source runs with
  make dist DEBIANBASE=y
same as with simple
  make dist
and builds debian-based version without errors.

I hope you will find this useful and apply it upstream.

Best regards


PS: I find the last xend.patch useful here if init.d/xend is run before
xenfs kernel module is loaded. Mount attempt autoloads the module. Otherwise
mount is never attempted. Is it ok to load xenfs module so late in the boot
process? If so, the last patch might also be interesting for upload, right?


On Mon, Jul 12, 2010 at 4:08 AM, Bruce Edge <bruce.edge@gmail.com> wrote:

> FYI -
>
> You could submit a patch to the Xen Gods directly and it would be accepted.
>
> I already got the debug options accepted in xen-unstable, so they do listen
> to people who have never contributed before.
> (21752 (29e545151078) tools/debugger/gdbsx: build enabled by default)
>
> -Bruce
>
>
> ---------- Forwarded message ----------
> From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Date: Wed, Jul 7, 2010 at 4:19 AM
> Subject: Re: [Xen-devel] Xen build - Debian vs Redhat layout patch options
> To: Bruce Edge <bruce.edge@gmail.com>
> Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
>
>
> On Wed, 7 Jul 2010, Bruce Edge wrote:
> > What's the right way to address these sort RedHat vs. Debian things in
> the Xen build?
> >
> > - rm -f  $(D)$(CONFIG_DIR)/sysconfig/xendomains
> > + rm -f  $(D)$(CONFIG_DIR)/default/xendomains
> >
> > - mkdir -p /var/lock/subsys
> > - touch /var/lock/subsys/xend
> > + mkdir -p /var/lock
> > + touch /var/lock/xend
> >
> > Can I submit a patch that uses a config var to switch on which path use ?
> >
> > Or, where should such a build time switch go? Env, or?
> > ...assuming that it's even an option.
> >
> > There's a couple of different downstream patches that others are
> maintaining to handle this kind of stuff, but that lag
> > behind the xen-unstable tree and it seems like an upstream patch to
> handle this distro variation in the Xen build itself
> > would be a better long term solution.
> >
>
> A way to switch between the two would be nice, I would accept a patch
> that accomplish that using a config var (something in Config.mk ?.
> The default value of this config variable might be detected looking at
> the existence of /etc/sysconfig or /etc/default.
>
> Keep in mind that besides sysconfig vs. default there are other subtle
> differences, like the chkconfig line in the init scripts
> (tools/hotplug/Linux/init.d/xencommons for example).
>
>