[PATCH v2] tools: Improve make deb

[PATCH v2] tools: Improve make deb

[fantonifabio]

From: Fabio Fantoni <fabio.fantoni@heliman.it>

Changes from v1:
- Added on description that this make a build for testing only.
- Improved add/remove of main service.

I reposted this patch after one year because I see recent
interest of some users about complete Xen debian package.
I also thinks like Stefano and Ian it's more important help to
improve official package and make here only this small
improvements.
I'll done improvements of posts of one year ago except for
remove of services that I think is useful but the main
change for good testing deb are remove of version from name
and add of conf file.
I started testing experimental debian packages of qemu and
seabios 2 months ago, I'll do the patch to integrate them
into experimental xen package if no one will do it.
So there will finally be complete xen even in official deb.

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
---
 tools/misc/mkdeb |   30 ++++++++++++++++++++++++------
 1 file changed, 24 insertions(+), 6 deletions(-)

diff --git a/tools/misc/mkdeb b/tools/misc/mkdeb
index 2e40747..fe7e1b1 100644
--- a/tools/misc/mkdeb
+++ b/tools/misc/mkdeb
@@ -33,7 +33,7 @@ fi
 # Fill in the debian boilerplate
 mkdir -p deb/DEBIAN
 cat >deb/DEBIAN/control <<EOF
-Package: xen-upstream-$version
+Package: xen-upstream
 Source: xen-upstream
 Version: $version
 Architecture: $arch
@@ -41,15 +41,33 @@ Maintainer: Unmaintained snapshot
 Section: admin
 Priority: optional
 Installed-Size: $(du -ks deb | cut -f1)
-Description: Xen hypervisor and tools, version $version
- This package contains the Xen hypervisor and associated tools, built
- from a source tree.  It is not a fully packaged and supported Xen, just
- the output of a xen "make dist" wrapped in a .deb to make it easy to
- uninstall.
+Description: Xen testing build, version $version
+ Warning: This is a custom testing build of Xen; it is not an
+ officially supported Debian package. Please not distribute.
+ It is just the output of a xen "make dist" wrapped in a .deb
+ to make it easy to update and uninstall.
+EOF
+cat >deb/DEBIAN/conffiles <<EOF
+/etc/xen/xl.conf
+/etc/xen/xend-config.sxp
+/etc/default/xendomains
+/etc/default/xencommons
+EOF
+cat >deb/DEBIAN/postinst <<EOF
+#!/bin/bash -e
+insserv xencommons &&
+insserv xendomains
+EOF
+cat >deb/DEBIAN/postrm <<EOF
+#!/bin/bash -e
+insserv -r xendomains &&
+insserv -r xencommons
 EOF
 
 # Package it up
 chown -R root:root deb
+chmod +x deb/DEBIAN/postinst
+chmod +x deb/DEBIAN/postrm
 dpkg --build deb xen-upstream-$version.deb
 
 # Tidy up after ourselves
-- 
1.7.9.5

Re: [PATCH v2] tools: Improve make deb

[Stefano Stabellini]

On Tue, 26 Feb 2013, fantonifabio@tiscali.it wrote:
> From: Fabio Fantoni <fabio.fantoni@heliman.it>
> 
> Changes from v1:
> - Added on description that this make a build for testing only.
> - Improved add/remove of main service.
> 
> I reposted this patch after one year because I see recent
> interest of some users about complete Xen debian package.
> I also thinks like Stefano and Ian it's more important help to
> improve official package and make here only this small
> improvements.
> I'll done improvements of posts of one year ago except for
> remove of services that I think is useful but the main
> change for good testing deb are remove of version from name
> and add of conf file.
> I started testing experimental debian packages of qemu and
> seabios 2 months ago, I'll do the patch to integrate them
> into experimental xen package if no one will do it.
> So there will finally be complete xen even in official deb.
> 
> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
> ---
>  tools/misc/mkdeb |   30 ++++++++++++++++++++++++------
>  1 file changed, 24 insertions(+), 6 deletions(-)
> 
> diff --git a/tools/misc/mkdeb b/tools/misc/mkdeb
> index 2e40747..fe7e1b1 100644
> --- a/tools/misc/mkdeb
> +++ b/tools/misc/mkdeb
> @@ -33,7 +33,7 @@ fi
>  # Fill in the debian boilerplate
>  mkdir -p deb/DEBIAN
>  cat >deb/DEBIAN/control <<EOF
> -Package: xen-upstream-$version
> +Package: xen-upstream
>  Source: xen-upstream
>  Version: $version
>  Architecture: $arch
> @@ -41,15 +41,33 @@ Maintainer: Unmaintained snapshot
>  Section: admin
>  Priority: optional
>  Installed-Size: $(du -ks deb | cut -f1)
> -Description: Xen hypervisor and tools, version $version
> - This package contains the Xen hypervisor and associated tools, built
> - from a source tree.  It is not a fully packaged and supported Xen, just
> - the output of a xen "make dist" wrapped in a .deb to make it easy to
> - uninstall.
> +Description: Xen testing build, version $version
> + Warning: This is a custom testing build of Xen; it is not an
> + officially supported Debian package. Please not distribute.
> + It is just the output of a xen "make dist" wrapped in a .deb
> + to make it easy to update and uninstall.
> +EOF
> +cat >deb/DEBIAN/conffiles <<EOF
> +/etc/xen/xl.conf
> +/etc/xen/xend-config.sxp
> +/etc/default/xendomains
> +/etc/default/xencommons
> +EOF
> +cat >deb/DEBIAN/postinst <<EOF
> +#!/bin/bash -e
> +insserv xencommons &&
> +insserv xendomains
> +EOF
> +cat >deb/DEBIAN/postrm <<EOF
> +#!/bin/bash -e
> +insserv -r xendomains &&
> +insserv -r xencommons
>  EOF
>  
>  # Package it up
>  chown -R root:root deb
> +chmod +x deb/DEBIAN/postinst
> +chmod +x deb/DEBIAN/postrm
>  dpkg --build deb xen-upstream-$version.deb
>  
>  # Tidy up after ourselves

All the changes look good to me

Re: [PATCH v2] tools: Improve make deb

[Ian Campbell]

On Tue, 2013-02-26 at 12:58 +0000, Stefano Stabellini wrote:
> > +cat >deb/DEBIAN/postrm <<EOF
> > +#!/bin/bash -e
> > +insserv -r xendomains &&
> > +insserv -r xencommons
[...]
> All the changes look good to me

This one certainly isn't, calling insserv directly in a pre/post inst is
not the correct Debian interface to use.

Better to call update-rc.d I think, or use dh_installinit (and grow a
build time dependency on debhelper).

Ian.

Re: [PATCH v2] tools: Improve make deb

[Stefano Stabellini]

On Tue, 26 Feb 2013, Ian Campbell wrote:
> On Tue, 2013-02-26 at 12:58 +0000, Stefano Stabellini wrote:
> > > +cat >deb/DEBIAN/postrm <<EOF
> > > +#!/bin/bash -e
> > > +insserv -r xendomains &&
> > > +insserv -r xencommons
> [...]
> > All the changes look good to me
> 
> This one certainly isn't, calling insserv directly in a pre/post inst is
> not the correct Debian interface to use.
> 
> Better to call update-rc.d I think, or use dh_installinit (and grow a
> build time dependency on debhelper).

I am _very_ ignorant in deb packaging, but this wiki

http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot

states:

"In Debian releases prior to 6.0, a service could be added with update-rc.d:

update-rc.d mydaemon defaults

Starting with Debian 6.0, the insserv command is used instead, if dependency-based booting is enabled:

insserv mydaemon"

but maybe this is the recommended thing to do for sysadmins, not for
packagers?

Re: [PATCH v2] tools: Improve make deb

[Ian Campbell]

On Tue, 2013-02-26 at 13:12 +0000, Stefano Stabellini wrote:
> On Tue, 26 Feb 2013, Ian Campbell wrote:
> > On Tue, 2013-02-26 at 12:58 +0000, Stefano Stabellini wrote:
> > > > +cat >deb/DEBIAN/postrm <<EOF
> > > > +#!/bin/bash -e
> > > > +insserv -r xendomains &&
> > > > +insserv -r xencommons
> > [...]
> > > All the changes look good to me
> > 
> > This one certainly isn't, calling insserv directly in a pre/post inst is
> > not the correct Debian interface to use.
> > 
> > Better to call update-rc.d I think, or use dh_installinit (and grow a
> > build time dependency on debhelper).
> 
> I am _very_ ignorant in deb packaging, but this wiki
> [...]
>  maybe this is the recommended thing to do for sysadmins, not for
> packagers?

AIUI, yes. The document to refer to for anything to do with Debian
Packaging is the Debian Policy Manual: 
        http://www.debian.org/doc/debian-policy/

In this case: 
        http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.3.3
        
        Maintainers should use the abstraction layer provided by the
        update-rc.d and invoke-rc.d programs to deal with initscripts in
        their packages' scripts such as postinst, prerm and postrm.
        
        Directly managing the /etc/rc?.d links and directly invoking
        the /etc/init.d/ initscripts should be done only by packages
        providing the initscript subsystem (such as sysv-rc and
        file-rc). 

Ian.

Re: [PATCH v2] tools: Improve make deb

[Fabio Fantoni]

Il 26/02/2013 14:18, Ian Campbell ha scritto:
> On Tue, 2013-02-26 at 13:12 +0000, Stefano Stabellini wrote:
>> On Tue, 26 Feb 2013, Ian Campbell wrote:
>>> On Tue, 2013-02-26 at 12:58 +0000, Stefano Stabellini wrote:
>>>>> +cat >deb/DEBIAN/postrm <<EOF
>>>>> +#!/bin/bash -e
>>>>> +insserv -r xendomains &&
>>>>> +insserv -r xencommons
>>> [...]
>>>> All the changes look good to me
>>> This one certainly isn't, calling insserv directly in a pre/post inst is
>>> not the correct Debian interface to use.
>>>
>>> Better to call update-rc.d I think, or use dh_installinit (and grow a
>>> build time dependency on debhelper).
>> I am _very_ ignorant in deb packaging, but this wiki
>> [...]
>>   maybe this is the recommended thing to do for sysadmins, not for
>> packagers?
> AIUI, yes. The document to refer to for anything to do with Debian
> Packaging is the Debian Policy Manual:
>          http://www.debian.org/doc/debian-policy/
>
> In this case:
>          http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.3.3
>          
>          Maintainers should use the abstraction layer provided by the
>          update-rc.d and invoke-rc.d programs to deal with initscripts in
>          their packages' scripts such as postinst, prerm and postrm.
>          
>          Directly managing the /etc/rc?.d links and directly invoking
>          the /etc/init.d/ initscripts should be done only by packages
>          providing the initscript subsystem (such as sysv-rc and
>          file-rc).
>
> Ian.
>
Sorry, Ian is right on this. I learned how to create deb packages 
according to the standards in the last months, I had better double check 
the patch.
I'll redo init with update-rc.d in next patch version.
The debian folder with compliance of deb policy 3.9.4 is probably loss 
of time that I can better use helping the official package.
Are there other important things to do in "make deb"? Probably is 
sufficent, I used it for my testing system for one year for hundreds of 
fast test build without problem.

Re: [PATCH v2] tools: Improve make deb

[Alex Bligh]

--On 26 February 2013 13:09:18 +0000 Ian Campbell <Ian.Campbell@citrix.com> 
wrote:

> On Tue, 2013-02-26 at 12:58 +0000, Stefano Stabellini wrote:
>> > +cat >deb/DEBIAN/postrm <<EOF
>> > +#!/bin/bash -e
>> > +insserv -r xendomains &&
>> > +insserv -r xencommons
> [...]
>> All the changes look good to me
>
> This one certainly isn't, calling insserv directly in a pre/post inst is
> not the correct Debian interface to use.
>
> Better to call update-rc.d I think, or use dh_installinit (and grow a
> build time dependency on debhelper).

Or better yet, put a .init file in your debian directory and use the
normal dh_tools to do it.

-- 
Alex Bligh

Re: [PATCH v2] tools: Improve make deb

[Alex Bligh]

--On 26 February 2013 15:16:44 +0100 Fabio Fantoni 
<fabio.fantoni@heliman.it> wrote:

> Sorry, Ian is right on this. I learned how to create deb packages
> according to the standards in the last months, I had better double check
> the patch.
> I'll redo init with update-rc.d in next patch version.

Feel free to steal the code from my minideb patch.

-- 
Alex Bligh

Re: [PATCH v2] tools: Improve make deb

[Fabio Fantoni]

Il 26/02/2013 15:23, Alex Bligh ha scritto:
>
>
> --On 26 February 2013 15:16:44 +0100 Fabio Fantoni 
> <fabio.fantoni@heliman.it> wrote:
>
>> Sorry, Ian is right on this. I learned how to create deb packages
>> according to the standards in the last months, I had better double check
>> the patch.
>> I'll redo init with update-rc.d in next patch version.
>
> Feel free to steal the code from my minideb patch.
>
Your package is using debhelper and devscripts, here I'll do only 
minimal deb for "make dist" that seem sufficent for devel/testing.
About your package for production use is very important  to remove 
version from name to make it correctly upgradable.
If you want to do complete xen package to add for example in ubuntu 
launchpad until debian official will be complete, these can be useful:
- use seabios of debian repository using this patch (already tested and 
working):
http://anonscm.debian.org/viewvc/pkg-xen/trunk/xen/debian/patches/tools-firmware-seabios-packaged.diff?view=markup
- use upstream qemu 1.3 or 1.4 from repository (patch to do), I already 
tested qemu package from debian experimental manually, is full working 
and with also spice and usbredir included (missed for now on upstream 
xen build of qemu-xen)

I think the best thing is test and help official debian package, if I 
remember well was:
svn co svn://svn.debian.org/pkg-xen/trunk
# Put the debian folder into xen souce folder
# Use quilt for update patches if you use earlier version
fakeroot debian/rules debian/control # to generate control file
debuild -i -b -us -uc # To test the build

When I have sufficent time I'll help it.

@Ian or Stefano:
About use upstream qemu from debian package on xen debian package:
Do I need to only remove the build (similar to seabios packaged patch) 
or may I also need to patch libxl/xm?

Re: [PATCH v2] tools: Improve make deb

[Ian Campbell]

On Tue, 2013-02-26 at 15:03 +0000, Fabio Fantoni wrote:
> @Ian or Stefano:
> About use upstream qemu from debian package on xen debian package:
> Do I need to only remove the build (similar to seabios packaged patch)
> or may I also need to patch libxl/xm?

Probably you'd need to patch libxl (but not xm) too.

On my todo list I have an action to make the configure script understand
--with-system-qemu=PATH, which would disable the qemu-xen build and
cause libxl to use $PATH (default /usr/bin/qemu?) instead
of /usr/lib/xen/bin/blah. If someone else were to get there first that
would be awesome!

./configure --(enable|disable)-qemu-traditional (i.e. just turn the
build off and on) would be quite useful too I think. As would making
libxl handle the absence of either a little more gracefully.

Ian.

Re: [PATCH v2] tools: Improve make deb

[Fabio Fantoni]

Il 26/02/2013 16:12, Ian Campbell ha scritto:
> On Tue, 2013-02-26 at 15:03 +0000, Fabio Fantoni wrote:
>> @Ian or Stefano:
>> About use upstream qemu from debian package on xen debian package:
>> Do I need to only remove the build (similar to seabios packaged patch)
>> or may I also need to patch libxl/xm?
> Probably you'd need to patch libxl (but not xm) too.
>
> On my todo list I have an action to make the configure script understand
> --with-system-qemu=PATH, which would disable the qemu-xen build and
> cause libxl to use $PATH (default /usr/bin/qemu?) instead
> of /usr/lib/xen/bin/blah. If someone else were to get there first that
> would be awesome!
>
> ./configure --(enable|disable)-qemu-traditional (i.e. just turn the
> build off and on) would be quite useful too I think. As would making
> libxl handle the absence of either a little more gracefully.
>
> Ian.
>
Thanks for the info, your idea for upstream xen instead is better than 
mine on debian patches.
Unfortunately for the moment I not have sufficent time to do this task.
The default qemu probably is good /usr/bin/qemu-system-x86_64, tested 
and full working on debian (not know about different distros), 
/usr/bin/qemu link to i386 which has some bugs (for example one or more 
important/critical with spice, that seem present also in other distros).
Following your indication it would be useful to add also the options to 
use system seabios for example --with-system-seabios=PATH, which is 
faster to do.

Re: [PATCH v2] tools: Improve make deb

[Ian Campbell]

On Tue, 2013-02-26 at 15:40 +0000, Fabio Fantoni wrote:
> Il 26/02/2013 16:12, Ian Campbell ha scritto:
> > On Tue, 2013-02-26 at 15:03 +0000, Fabio Fantoni wrote:
> >> @Ian or Stefano:
> >> About use upstream qemu from debian package on xen debian package:
> >> Do I need to only remove the build (similar to seabios packaged patch)
> >> or may I also need to patch libxl/xm?
> > Probably you'd need to patch libxl (but not xm) too.
> >
> > On my todo list I have an action to make the configure script understand
> > --with-system-qemu=PATH, which would disable the qemu-xen build and
> > cause libxl to use $PATH (default /usr/bin/qemu?) instead
> > of /usr/lib/xen/bin/blah. If someone else were to get there first that
> > would be awesome!
> >
> > ./configure --(enable|disable)-qemu-traditional (i.e. just turn the
> > build off and on) would be quite useful too I think. As would making
> > libxl handle the absence of either a little more gracefully.
> >
> > Ian.
> >
> Thanks for the info, your idea for upstream xen instead is better than 
> mine on debian patches.
> Unfortunately for the moment I not have sufficent time to do this task.

No worries, it'll sit on my list until I get to it ;-)

> The default qemu probably is good /usr/bin/qemu-system-x86_64, tested 
> and full working on debian (not know about different distros), 
> /usr/bin/qemu link to i386 which has some bugs (for example one or more 
> important/critical with spice, that seem present also in other distros).
> Following your indication it would be useful to add also the options to 
> use system seabios for example --with-system-seabios=PATH, which is 
> faster to do.

Yes, that would be useful too. Sigh, that's another entry on the TODO
list ;-)

Ian.

Re: [PATCH v2] tools: Improve make deb

[Ian Jackson]

fantonifabio@tiscali.it writes ("[Xen-devel] [PATCH v2] tools: Improve make deb"):
> Changes from v1:
> - Added on description that this make a build for testing only.
> - Improved add/remove of main service.

I'm not convinced that this is a good idea.

Firstly, the point of the "make deb" target is not to provide a
proper, fully featured, Debian binary package.  That work should be
done in Debian.

The point of our `make deb' is to provide a simple way for people
using Debian-derived systems to get the bits onto their disk and
remove them again afterwards.

> diff --git a/tools/misc/mkdeb b/tools/misc/mkdeb
> index 2e40747..fe7e1b1 100644
> --- a/tools/misc/mkdeb
> +++ b/tools/misc/mkdeb
> @@ -33,7 +33,7 @@ fi
>  # Fill in the debian boilerplate
>  mkdir -p deb/DEBIAN
>  cat >deb/DEBIAN/control <<EOF
> -Package: xen-upstream-$version
> +Package: xen-upstream

I don't object to this change because they're not coinstallable
anyway.

> +cat >deb/DEBIAN/conffiles <<EOF
> +/etc/xen/xl.conf
> +/etc/xen/xend-config.sxp
> +/etc/default/xendomains
> +/etc/default/xencommons
> +EOF

This is fine too IMO but it should be done with
"find -type f" rather than listing these files explicitly.

> +cat >deb/DEBIAN/postinst <<EOF
> +#!/bin/bash -e
> +insserv xencommons &&
> +insserv xendomains
> +EOF
> +cat >deb/DEBIAN/postrm <<EOF
> +#!/bin/bash -e
> +insserv -r xendomains &&
> +insserv -r xencommons
>  EOF

I do object to these.  "Getting the bits onto your system" doesn't
include automatically starting the daemons.

(Others have pointed out that this isn't the way to do it, anyway.)

Thanks,
Ian.

Re: [PATCH v2] tools: Improve make deb

[Stefano Stabellini]

On Tue, 26 Feb 2013, Ian Jackson wrote:
> Firstly, the point of the "make deb" target is not to provide a
> proper, fully featured, Debian binary package.  That work should be
> done in Debian.

If we are allowing people to build a deb package from xen-unstable we
should do it right.
Also there are many reasons why somebody would want to rebuild his
own Xen package from xen-unstable instead of the deb source.


> I do object to these.  "Getting the bits onto your system" doesn't
> include automatically starting the daemons.

No matter what we think the objective of the deb target is, it cannot be
an excuse to do only half of the job.
Even if it is just for testing, I would want the init scripts to
be started automatically on my testbox, why should I do that manually?

Re: [PATCH v2] tools: Improve make deb

[Ian Campbell]

On Tue, 2013-02-26 at 16:45 +0000, Stefano Stabellini wrote:
> Also there are many reasons why somebody would want to rebuild his
> own Xen package from xen-unstable instead of the deb source.

Nothing is stopping them doing this, but the deb target in the xen tree
is not aimed at them.

> > I do object to these.  "Getting the bits onto your system" doesn't
> > include automatically starting the daemons.
> 
> No matter what we think the objective of the deb target is, it cannot be
> an excuse to do only half of the job.

The current deb target does exactly what it was intended to do, no more
and no less. It does not do half a job at its intended goal. Note that
it's goal is not and never was to provide a completely usable package
for end users.

> Even if it is just for testing, I would want the init scripts to
> be started automatically on my testbox, why should I do that manually?

Because the deb target is a "removable tarball" nothing more. Do you
expect that a tarball would do this?

Do you expect that this deb package should also frob your bootloader
configuration? What about setting up bridged networking? Where do we
draw the line?

If we cannot agree on this then I propose we remove the existing deb
target, since I don't think a full and proper .deb (or .rpm or ebuild or
xxx) packaging has any place in the main Xen tree, that is what the
distros are for. Otherwise we are going to be constantly rehashing these
same old arguments -- we've already been over this more than once in
this very thread!

Ian.

Re: [PATCH v2] tools: Improve make deb

[Tim Deegan]

At 16:45 +0000 on 26 Feb (1361897101), Stefano Stabellini wrote:
> > I do object to these.  "Getting the bits onto your system" doesn't
> > include automatically starting the daemons.
> 
> No matter what we think the objective of the deb target is, it cannot be
> an excuse to do only half of the job.

Speaking as its author, I know what the objective is: to unpack what
'make install' would do, and remove it again afterwards.  The fact that
it uses a .deb package for that is unfortunate, because it leads people
to think of it as a packaged Xen.  Perhaps I ought to have rolled my own
manifest for uninstalling.

Tim.

Re: [PATCH v2] tools: Improve make deb

[Ian Jackson]

Tim Deegan writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
> Speaking as its author, I know what the objective is: to unpack what
> 'make install' would do, and remove it again afterwards.  The fact that
> it uses a .deb package for that is unfortunate, because it leads people
> to think of it as a packaged Xen.  Perhaps I ought to have rolled my own
> manifest for uninstalling.

I think we should fix this problem by improving the documentation.

>From a technical point of view, a .deb is definitely the right thing.

And I do think that there is a plausible argument that the config
files ought not to be just blatted over the top of your system.  (If
"make install" does that then there's the same argument there - I
don't think "make install" should trash existing config.)

If you _want_ the config files trashed on deinstallation dpkg --purge IYF

Ian.

Re: [PATCH v2] tools: Improve make deb

[Tim Deegan]

At 17:12 +0000 on 26 Feb (1361898743), Ian Jackson wrote:
> Tim Deegan writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
> > Speaking as its author, I know what the objective is: to unpack what
> > 'make install' would do, and remove it again afterwards.  The fact that
> > it uses a .deb package for that is unfortunate, because it leads people
> > to think of it as a packaged Xen.  Perhaps I ought to have rolled my own
> > manifest for uninstalling.
> 
> I think we should fix this problem by improving the documentation.
> 
> From a technical point of view, a .deb is definitely the right thing.
> 
> And I do think that there is a plausible argument that the config
> files ought not to be just blatted over the top of your system.  (If
> "make install" does that then there's the same argument there - I
> don't think "make install" should trash existing config.)

AFAIK 'make install' does; certainly some room for improvement in that
are.  In 'make deb' treating config files as normal data is deliberate.
I don't want remnants of old tests contaminating my new install - that
was the whole point.

Tim.

Re: [PATCH v2] tools: Improve make deb

[Ian Jackson]

Tim Deegan writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
> At 17:12 +0000 on 26 Feb (1361898743), Ian Jackson wrote:
> > And I do think that there is a plausible argument that the config
> > files ought not to be just blatted over the top of your system.  (If
> > "make install" does that then there's the same argument there - I
> > don't think "make install" should trash existing config.)
> 
> AFAIK 'make install' does; certainly some room for improvement in that
> are.  In 'make deb' treating config files as normal data is deliberate.
> I don't want remnants of old tests contaminating my new install - that
> was the whole point.

If you say dpkg --purge they will be entirely removed, even if marked
as conffiles.

Ian.

Re: [PATCH v2] tools: Improve make deb

[Tim Deegan]

At 17:22 +0000 on 26 Feb (1361899321), Ian Jackson wrote:
> Tim Deegan writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
> > At 17:12 +0000 on 26 Feb (1361898743), Ian Jackson wrote:
> > > And I do think that there is a plausible argument that the config
> > > files ought not to be just blatted over the top of your system.  (If
> > > "make install" does that then there's the same argument there - I
> > > don't think "make install" should trash existing config.)
> > 
> > AFAIK 'make install' does; certainly some room for improvement in that
> > are.  In 'make deb' treating config files as normal data is deliberate.
> > I don't want remnants of old tests contaminating my new install - that
> > was the whole point.
> 
> If you say dpkg --purge they will be entirely removed, even if marked
> as conffiles.

Yes, but that assumes that the default behaviour shouuld be to leave
them around, which I dispute.  Again, using .deb leads to thinking about
how a real package would behave. :)

Tim.

Re: [PATCH v2] tools: Improve make deb

[Stefano Stabellini]

On Tue, 26 Feb 2013, Tim Deegan wrote:
> At 17:22 +0000 on 26 Feb (1361899321), Ian Jackson wrote:
> > Tim Deegan writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
> > > At 17:12 +0000 on 26 Feb (1361898743), Ian Jackson wrote:
> > > > And I do think that there is a plausible argument that the config
> > > > files ought not to be just blatted over the top of your system.  (If
> > > > "make install" does that then there's the same argument there - I
> > > > don't think "make install" should trash existing config.)
> > > 
> > > AFAIK 'make install' does; certainly some room for improvement in that
> > > are.  In 'make deb' treating config files as normal data is deliberate.
> > > I don't want remnants of old tests contaminating my new install - that
> > > was the whole point.
> > 
> > If you say dpkg --purge they will be entirely removed, even if marked
> > as conffiles.
> 
> Yes, but that assumes that the default behaviour shouuld be to leave
> them around, which I dispute.  Again, using .deb leads to thinking about
> how a real package would behave. :)

Maybe we should produce a tgz instead (plain or Slackware style).
I wouldn't want to create wrong expectations: it is better to build no
packages than building "broken" packages. (Of course I still think the
best choice would be to produce good packages.)

Re: [PATCH v2] tools: Improve make deb

[Ian Campbell]

On Tue, 2013-02-26 at 17:33 +0000, Stefano Stabellini wrote:
> On Tue, 26 Feb 2013, Tim Deegan wrote:
> > At 17:22 +0000 on 26 Feb (1361899321), Ian Jackson wrote:
> > > Tim Deegan writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
> > > > At 17:12 +0000 on 26 Feb (1361898743), Ian Jackson wrote:
> > > > > And I do think that there is a plausible argument that the config
> > > > > files ought not to be just blatted over the top of your system.  (If
> > > > > "make install" does that then there's the same argument there - I
> > > > > don't think "make install" should trash existing config.)
> > > > 
> > > > AFAIK 'make install' does; certainly some room for improvement in that
> > > > are.  In 'make deb' treating config files as normal data is deliberate.
> > > > I don't want remnants of old tests contaminating my new install - that
> > > > was the whole point.
> > > 
> > > If you say dpkg --purge they will be entirely removed, even if marked
> > > as conffiles.
> > 
> > Yes, but that assumes that the default behaviour shouuld be to leave
> > them around, which I dispute.  Again, using .deb leads to thinking about
> > how a real package would behave. :)
> 
> Maybe we should produce a tgz instead (plain or Slackware style).
> I wouldn't want to create wrong expectations: it is better to build no
> packages than building "broken" packages. (Of course I still think the
> best choice would be to produce good packages.)

I think you have massively underestimated the development effort and
maintenance burden of producing good packages. Again: That is what the
distros do, and they do it well and in a far more scalable fashion than
we ever could.

Ian.

Re: [PATCH v2] tools: Improve make deb

[Ian Jackson]

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
> Maybe we should produce a tgz instead (plain or Slackware style).

This fails to solve the problem Tim was trying to solve, which is
to make it easy to remove previous versions.

> I wouldn't want to create wrong expectations: it is better to build no
> packages than building "broken" packages. (Of course I still think the
> best choice would be to produce good packages.)

I think we can engage in better expectations management.  Perhaps we
could rename the target.

Ian.

Re: [PATCH v2] tools: Improve make deb

[Tim Deegan]

At 17:33 +0000 on 26 Feb (1361899998), Stefano Stabellini wrote:
> On Tue, 26 Feb 2013, Tim Deegan wrote:
> > At 17:22 +0000 on 26 Feb (1361899321), Ian Jackson wrote:
> > > Tim Deegan writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
> > > > At 17:12 +0000 on 26 Feb (1361898743), Ian Jackson wrote:
> > > > > And I do think that there is a plausible argument that the config
> > > > > files ought not to be just blatted over the top of your system.  (If
> > > > > "make install" does that then there's the same argument there - I
> > > > > don't think "make install" should trash existing config.)
> > > > 
> > > > AFAIK 'make install' does; certainly some room for improvement in that
> > > > are.  In 'make deb' treating config files as normal data is deliberate.
> > > > I don't want remnants of old tests contaminating my new install - that
> > > > was the whole point.
> > > 
> > > If you say dpkg --purge they will be entirely removed, even if marked
> > > as conffiles.
> > 
> > Yes, but that assumes that the default behaviour shouuld be to leave
> > them around, which I dispute.  Again, using .deb leads to thinking about
> > how a real package would behave. :)
> 
> Maybe we should produce a tgz instead (plain or Slackware style).
> I wouldn't want to create wrong expectations: it is better to build no
> packages than building "broken" packages.

That's fair.  The existing deb target is just the configuration that I
find useful, and perhaps no more reasonable than anyone else's personal
preference.  I'm happy to take my ball and go home; I can use the mkdeb
script from my home directory just as well. :)

> (Of course I still think the
> best choice would be to produce good packages.)

Sure, but that's a lot more work than I've seen in any of these patches
so far.  Are you volunteering?

Tim.

Re: [PATCH v2] tools: Improve make deb

[Sander Eikelenboom]

Tuesday, February 26, 2013, 6:20:09 PM, you wrote:

> At 17:12 +0000 on 26 Feb (1361898743), Ian Jackson wrote:
>> Tim Deegan writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
>> > Speaking as its author, I know what the objective is: to unpack what
>> > 'make install' would do, and remove it again afterwards.  The fact that
>> > it uses a .deb package for that is unfortunate, because it leads people
>> > to think of it as a packaged Xen.  Perhaps I ought to have rolled my own
>> > manifest for uninstalling.
>> 
>> I think we should fix this problem by improving the documentation.
>> 
>> From a technical point of view, a .deb is definitely the right thing.
>> 
>> And I do think that there is a plausible argument that the config
>> files ought not to be just blatted over the top of your system.  (If
>> "make install" does that then there's the same argument there - I
>> don't think "make install" should trash existing config.)

> AFAIK 'make install' does; certainly some room for improvement in that
> are.  In 'make deb' treating config files as normal data is deliberate.
> I don't want remnants of old tests contaminating my new install - that
> was the whole point.

Would a option to ./configure to enable/disable the install of config and initfiles on make install (or a seperate build target for config files) make sense ?

--
Sander


> Tim.

Re: [PATCH v2] tools: Improve make deb

[Ian Jackson]

Sander Eikelenboom writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
> Would a option to ./configure to enable/disable the install of
> config and initfiles on make install (or a seperate build target for
> config files) make sense ?

No.  What this target needs is simplicitly and lack of argument.

I'd rather have a version that unconditionally overwrote things in
/etc than one with a bunch of knobs to twiddle in configure, or any of
the other exciting features proposed.

Ian.

Re: [PATCH v2] tools: Improve make deb

[Stefano Stabellini]

On Tue, 26 Feb 2013, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
> > Maybe we should produce a tgz instead (plain or Slackware style).
> 
> This fails to solve the problem Tim was trying to solve, which is
> to make it easy to remove previous versions.

That is true.
However Slackware can install and remove them (even though I understand
not many people are going to benefit from it).
alien can convert those tgz into a deb or an rpm. Overall it certainly
wouldn't be an improvement for Debian users, but after all they are not
the target anyway.


> > I wouldn't want to create wrong expectations: it is better to build no
> > packages than building "broken" packages. (Of course I still think the
> > best choice would be to produce good packages.)
> 
> I think we can engage in better expectations management.  Perhaps we
> could rename the target.

Right, that would be a step forward. Something that make it clear that
it isn't a proper deb. 

Re: [PATCH v2] tools: Improve make deb

[George Dunlap]

[-- Attachment #1.1: Type: text/plain, Size: 2114 bytes --]

On Tue, Feb 26, 2013 at 5:39 PM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> > Maybe we should produce a tgz instead (plain or Slackware style).
> > I wouldn't want to create wrong expectations: it is better to build no
> > packages than building "broken" packages. (Of course I still think the
> > best choice would be to produce good packages.)
>
> I think you have massively underestimated the development effort and
> maintenance burden of producing good packages. Again: That is what the
> distros do, and they do it well and in a far more scalable fashion than
> we ever could.
>


I can see the point of both sides -- we (at least the active developers)
don't want to get into real package management.  The point of keeping the
.deb as an "easy way to add and remove a tarball" is to avoid raising
expectations that we are going to maintain such a thing.

On the other hand, there is clearly a definite need for such a thing.
Saying "Debian or Ubuntu should be doing the packaging" is just not right
thinking IMHO.  We *want* (and *need*) to have active users to be using our
releases as soon as they come out, rather than waiting N years for them to
trickle through the Debian and Ubuntu packaging systems.  As has been said
before, building the Debian package involves all kinds of complications
regarding custom patches and so on.

What about this: We obviously have users who are keen to have this
functionality, and in fact who have made local versions of such
functionality to use themselves.  If one of them is willing to step up and
officially maintain such functionality (which would include responding to
bugs and updating things on a regular basis), then I think we should
consider accepting such a patch.  If it ever becomes unmaintained, then
we'll take it out.  That way the core devs won't have to be involved in
package management, but early-adopters will have the benefit of being able
to use Xen more easily.

In any case I would suggest keeping the current .deb target but renaming it
to something like "testdeb", to emphasize "this is for testing purposes
only".

Thoughts?
 -George

[-- Attachment #1.2: Type: text/html, Size: 2790 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH v2] tools: Improve make deb

[George Dunlap]

[-- Attachment #1.1: Type: text/plain, Size: 620 bytes --]

On Tue, Feb 26, 2013 at 5:57 PM, Stefano Stabellini <
stefano.stabellini@eu.citrix.com> wrote:

>
> > I think we can engage in better expectations management.  Perhaps we
> > could rename the target.
>
> Right, that would be a step forward. Something that make it clear that
> it isn't a proper deb.
>


Right -- the description in the .deb file already tries to make clear that
"this is not a proper deb"; "make testdeb" or something like that would
hopefully make it more obvious.  ("make tardeb" maybe?)

That still won't change the fact that this is a bit of functionality that
lots of people really want.

 -George

[-- Attachment #1.2: Type: text/html, Size: 1188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH v2] tools: Improve make deb

[Ian Campbell]

On Wed, 2013-02-27 at 10:54 +0000, George Dunlap wrote:
> What about this: We obviously have users who are keen to have this
> functionality, and in fact who have made local versions of such
> functionality to use themselves.  If one of them is willing to step up
> and officially maintain such functionality (which would include
> responding to bugs and updating things on a regular basis), then I
> think we should consider accepting such a patch.  If it ever becomes
> unmaintained, then we'll take it out.  That way the core devs won't
> have to be involved in package management, but early-adopters will
> have the benefit of being able to use Xen more easily. 

IMHO the right way to provide this is for that someone to provide
regular snapshot packages based on the distro packaging. Even better
would be to work with the distro package maintainers and use the
facilities which they provide e.g. Debian's Experimental distro. This
has the added advantages of helping the distros to have 4.3 packages
more quickly after 4.3 is released as well as helping the distro instead
of duplicating their effort.

Of course this is all just hand waving unless someone steps, and when
they do it is up to them how they achieve the goal.

Ian.

Re: [PATCH v2] tools: Improve make deb

[Ian Campbell]

On Tue, 2013-02-26 at 17:57 +0000, Stefano Stabellini wrote:
> 
> > I think we can engage in better expectations management.  Perhaps we
> > could rename the target.
> 
> Right, that would be a step forward. Something that make it clear that
> it isn't a proper deb. 


8<------

>From 9ca6f044bae834ec991e7a8c83623344f4701f87 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Wed, 27 Feb 2013 11:16:47 +0000
Subject: [PATCH] build: rename deb target as debball

"debball" by analogy with "tarball". Attempt to clarify the purpose of this
target in the comment.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 Makefile |    8 +++++---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index 2d3ed82..32efb70 100644
--- a/Makefile
+++ b/Makefile
@@ -137,9 +137,11 @@ world:
 	$(MAKE) kdelete
 	$(MAKE) dist
 
-# Package a build in a .deb file
-.PHONY: deb
-deb: dist
+# Package a build in a debball file, that is inside a .deb format
+# container to allow for easy and clean removal. This is not intended
+# to be a full featured policy compliant .deb package.
+.PHONY: debball
+debball: dist
 	fakeroot sh ./tools/misc/mkdeb $(XEN_ROOT) $$($(MAKE) -C xen xenversion | grep -v :)
 
 # clean doesn't do a kclean
-- 
1.7.2.5

Re: [PATCH v2] tools: Improve make deb

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 942 bytes --]

On Wed, 27 Feb 2013, George Dunlap wrote:
> What about this: We obviously have users who are keen to have this functionality, and in fact who have made local versions of
> such functionality to use themselves.  If one of them is willing to step up and officially maintain such functionality (which
> would include responding to bugs and updating things on a regular basis), then I think we should consider accepting such a
> patch.  If it ever becomes unmaintained, then we'll take it out.  That way the core devs won't have to be involved in package
> management, but early-adopters will have the benefit of being able to use Xen more easily.


I think that is the right way of thinking. After all we even have a
differentiation between maintainers and committers exactly for this sort
of cases (even though right now we aren't using it much).

So the question is, would anybody step up to maintain a proper deb build
target?

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH v2] tools: Improve make deb

[Ian Jackson]

Ian Campbell writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Wed, 27 Feb 2013 11:16:47 +0000
> Subject: [PATCH] build: rename deb target as debball
> 
> "debball" by analogy with "tarball". Attempt to clarify the purpose of this
> target in the comment.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

(I won't apply it just yet as we're maybe still arguing ...)

Ian.

Re: [PATCH v2] tools: Improve make deb

[Tim Deegan]

At 11:19 +0000 on 27 Feb (1361963955), Ian Campbell wrote:
> On Tue, 2013-02-26 at 17:57 +0000, Stefano Stabellini wrote:
> > 
> > > I think we can engage in better expectations management.  Perhaps we
> > > could rename the target.
> > 
> > Right, that would be a step forward. Something that make it clear that
> > it isn't a proper deb. 
> 
> 
> 8<------
> 
> From 9ca6f044bae834ec991e7a8c83623344f4701f87 Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Wed, 27 Feb 2013 11:16:47 +0000
> Subject: [PATCH] build: rename deb target as debball
> 
> "debball" by analogy with "tarball". Attempt to clarify the purpose of this
> target in the comment.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Tim Deegan <tim@xen.org>

> ---
>  Makefile |    8 +++++---
>  1 files changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index 2d3ed82..32efb70 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -137,9 +137,11 @@ world:
>  	$(MAKE) kdelete
>  	$(MAKE) dist
>  
> -# Package a build in a .deb file
> -.PHONY: deb
> -deb: dist
> +# Package a build in a debball file, that is inside a .deb format
> +# container to allow for easy and clean removal. This is not intended
> +# to be a full featured policy compliant .deb package.
> +.PHONY: debball
> +debball: dist
>  	fakeroot sh ./tools/misc/mkdeb $(XEN_ROOT) $$($(MAKE) -C xen xenversion | grep -v :)
>  
>  # clean doesn't do a kclean
> -- 
> 1.7.2.5
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: [PATCH v2] tools: Improve make deb

[Alex Bligh]

--On 27 February 2013 11:58:30 +0000 Stefano Stabellini 
<stefano.stabellini@eu.citrix.com> wrote:

> I think that is the right way of thinking. After all we even have a
> differentiation between maintainers and committers exactly for this sort
> of cases (even though right now we aren't using it much).
>
> So the question is, would anybody step up to maintain a proper deb build
> target?

If 'proper deb build target' means one like ubuntu (or debian which
I believe to be very similar) but without any custom code patches, yes,
I'll stick up my hand for that one. Note this makes more than one
package:

http://packages.ubuntu.com/search?keywords=xen-&searchon=names&suite=raring&section=all

which may or may not make it suitable as a 'tarball replacement'.

My approach would in essence be to borrow the Ubuntu/Debian packaging
and make it build with a proper debian/ directory, rather than using
a 'make deb' build target.

Bringing debian packaging upstream is (I believe) considered 'no bad
thing'.

I would however point out that there are others infinitely more
qualified than me to do this (Stefan Bader for instance - copied),
and such a person wants to do it I have no objection whatsoever.

-- 
Alex Bligh

Re: [PATCH v2] tools: Improve make deb

[Ian Campbell]

On Wed, 2013-02-27 at 20:00 +0000, Alex Bligh wrote:
> 
> Bringing debian packaging upstream is (I believe) considered 'no bad
> thing'. 

On the contrary, Debian discourages upstreams from including a debian/
directory in their releases.

Ian.

Re: [PATCH v2] tools: Improve make deb

[Stefan Bader]

[-- Attachment #1.1: Type: text/plain, Size: 1313 bytes --]

On 27.02.2013 21:07, Ian Campbell wrote:
> On Wed, 2013-02-27 at 20:00 +0000, Alex Bligh wrote:
>>
>> Bringing debian packaging upstream is (I believe) considered 'no bad
>> thing'. 
> 
> On the contrary, Debian discourages upstreams from including a debian/
> directory in their releases.
> 
> Ian.
> 
I would agree with Ian here. I am sorry, I have not read anything of the
previous discussion but if it is about having a simple way of getting a test
package for deb (and rpm) based systems, the make target approach which is not
using a debian directory sounds better. For testing you likely want just one
package and that does not necessarily need any documentation. And if that was
done in debian/ it would make the Debian maintainers job a pain because the
whole packaging is based on the orig tarball not having that directory. (And
FWIW Ubuntu derives from Debian, there are only changes if we really really have
to).

The kernel has a "make deb-pkg" approach as well. Though there things are a
little more simple as there are less locations which can be different to the
normal packages. That might be much harder to achieve for the Xen (not only but
anything with a mix of binaries and libraries to be put somewhere in parallel
but not interfering if not wanted).

-Stefan


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH v2] tools: Improve make deb

[Ian Campbell]

On Thu, 2013-02-28 at 09:40 +0000, Stefan Bader wrote:
> The kernel has a "make deb-pkg" approach as well. Though there things are a
> little more simple as there are less locations which can be different to the
> normal packages. That might be much harder to achieve for the Xen (not only but
> anything with a mix of binaries and libraries to be put somewhere in parallel
> but not interfering if not wanted).

Yes, I think the presence of numerous bits of userspace stuff which
cannot be coinstalled is what mainly makes this different to the kernel
situation.

Ian.

Re: [PATCH v2] tools: Improve make deb

[George Dunlap]

On 28/02/13 09:40, Stefan Bader wrote:
> On 27.02.2013 21:07, Ian Campbell wrote:
>> On Wed, 2013-02-27 at 20:00 +0000, Alex Bligh wrote:
>>> Bringing debian packaging upstream is (I believe) considered 'no bad
>>> thing'.
>> On the contrary, Debian discourages upstreams from including a debian/
>> directory in their releases.
>>
>> Ian.
>>
> I would agree with Ian here. I am sorry, I have not read anything of the
> previous discussion but if it is about having a simple way of getting a test
> package for deb (and rpm) based systems, the make target approach which is not
> using a debian directory sounds better. For testing you likely want just one
> package and that does not necessarily need any documentation. And if that was
> done in debian/ it would make the Debian maintainers job a pain because the
> whole packaging is based on the orig tarball not having that directory. (And
> FWIW Ubuntu derives from Debian, there are only changes if we really really have
> to).

Just to catch you up Stefan, the discussion isn't about having a simple 
way to get a test package.  We already have that target: "make deb" will 
create a .deb that when installed will have very similar effects to 
"make install" -- i.e., just copy a bunch of files into place.  The 
advantage of course being that the .deb keeps track of all the files 
which need to be *removed* as well, making it easier for developers.

What's being discussed is a more fully-featured .deb target.  The 
current output of "make deb" isn't really suitable for users -- it 
doesn't do anything with regard to setup, it doesn't test any 
dependencies, &c -- in other words, it doesn't do anything one normally 
expects from a mature package management system.

Generally speaking the Xen developers want to encourage users to use the 
packages available in their distro.  That's the best option for the 
majority of users.  However, there are "early-adopter" users who need to 
/ enjoy being on the bleeding edge -- meaning typically, on the very 
latest point release, as well as able and willing to test RCs before a 
release.  These users perform a very important role in the project, and 
so it is important (I think) to make it easy for them to download and 
install these versions.

Alex, what do you think about Ian's suggestion -- i.e., rather than 
integrate a full-featured .deb package into the Xen build system, 
intermittently use the Debian Xen target to create a set of .debs and 
make them available publicly somewhere?  If this was done once only for 
every new release, and then maybe once for each RC (or every other RC) 
before a release, it shouldn't be too much work I don't think.  I think 
we should probably be able to make space on the xen.org website 
somewhere to keep them.

Would that be useful for you, or do I misunderstand what it is you need?

(Also, I think that's what Ian was suggesting -- please correct me if 
I'm wrong, Ian!)

  -George

Re: [PATCH v2] tools: Improve make deb

[Ian Jackson]

George Dunlap writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
> Alex, what do you think about Ian's suggestion -- i.e., rather than 
> integrate a full-featured .deb package into the Xen build system, 
> intermittently use the Debian Xen target to create a set of .debs and 
> make them available publicly somewhere?

I think this is a good idea and should perhaps even be done nightly.

Ian.

Re: [PATCH v2] tools: Improve make deb

[George Dunlap]

On 28/02/13 11:53, Ian Jackson wrote:
> George Dunlap writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
>> Alex, what do you think about Ian's suggestion -- i.e., rather than
>> integrate a full-featured .deb package into the Xen build system,
>> intermittently use the Debian Xen target to create a set of .debs and
>> make them available publicly somewhere?
> I think this is a good idea and should perhaps even be done nightly.

You're suggesting integrating it into the automated build system, I presume?

  -George

Re: [PATCH v2] tools: Improve make deb

[Ian Jackson]

George Dunlap writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
> On 28/02/13 11:53, Ian Jackson wrote:
> > I think this is a good idea and should perhaps even be done nightly.
> 
> You're suggesting integrating it into the automated build system, I presume?

That would be best.  You'd end up with packages for master but not
staging.  And you'd end up with ones for the stable branches too.

What's needed is an automated production recipe which I don't think we
have.  It would probably also need a push gate for the Debian
packaging from Debian, to stop our tests being gummed up if the Debian
packaging changes incompatibly, and a commitment to maintain whatever
local changes we have that make it all work.

Ian.

Re: [PATCH v2] tools: Improve make deb [and 1 more messages]

[Ian Jackson]

Ian Jackson writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
> Ian Campbell writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
> > From: Ian Campbell <ian.campbell@citrix.com>
> > Date: Wed, 27 Feb 2013 11:16:47 +0000
> > Subject: [PATCH] build: rename deb target as debball
> > 
> > "debball" by analogy with "tarball". Attempt to clarify the purpose of this
> > target in the comment.
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Tim Deegan writes ("Re: [Xen-devel] [PATCH v2] tools: Improve make deb"):
> Acked-by: Tim Deegan <tim@xen.org>

Applied.

Ian.

Re: [PATCH v2] tools: Improve make deb

[Alex Bligh]

--On 28 February 2013 10:51:38 +0000 George Dunlap 
<george.dunlap@eu.citrix.com> wrote:

> Alex, what do you think about Ian's suggestion -- i.e., rather than
> integrate a full-featured .deb package into the Xen build system,
> intermittently use the Debian Xen target to create a set of .debs and
> make them available publicly somewhere?  If this was done once only for
> every new release, and then maybe once for each RC (or every other RC)
> before a release, it shouldn't be too much work I don't think.  I think
> we should probably be able to make space on the xen.org website somewhere
> to keep them.

Well, that wouldn't do me any harm or any good. What I want to do is
produce a .deb of the code I have fiddled with.

I think there are at least 3 use cases here:

1. Providing some sort of debian packaging allowing the unstable build
   to be used and installed in a normal way, to encourage testing of
   unstable. This needs init scripts etc. in it, but typically the
   user isn't making his own changes. This should be debuild thing
   with a debian directory (in my opinion), and might not want to be
   upstream in a conventional way.

2. Providing a .deb for the developer, with a bit more functionality
   than the .tgz (e.g. not stomping on configuration files), and
   arguably some init files, but essentially to let the developer
   install his own stuff. A make target is better here, partly because
   make from clean (which is what debuild does) takes ages.

3. Providing a minimalist install (e.g. without header files) of a
   development build - i.e. a small 'package' to take over to another
   machine to install for the purposes of testing - that's what
   my minideb target did. Again a make target is better here.


Task (1) is essentially making the debian or ubuntu packaging easily
available in unstable. I don't know the politically correct way to
do that. It could also be build periodically and made available
somewhere but that would be hard without taking at least an element
of the packaging upstream somewhere (else how it be built).

Task (2) could be done by fixing up the deb target a small amount.

Task (3) is what my minideb target did (see 'Xen 4.2 debian packaging'
thread), and I'm guessing is too arcane for most people, and I'm only
too happy to maintain it on a private branch.

-- 
Alex Bligh

Re: [PATCH v2] tools: Improve make deb

[Tim Deegan]

At 18:31 +0000 on 28 Feb (1362076272), Alex Bligh wrote:
> I think there are at least 3 use cases here:
> 
> 1. Providing some sort of debian packaging allowing the unstable build
>   to be used and installed in a normal way, to encourage testing of
>   unstable. This needs init scripts etc. in it, but typically the
>   user isn't making his own changes. This should be debuild thing
>   with a debian directory (in my opinion), and might not want to be
>   upstream in a conventional way.
> 
> 2. Providing a .deb for the developer, with a bit more functionality
>   than the .tgz (e.g. not stomping on configuration files), and
>   arguably some init files, but essentially to let the developer
>   install his own stuff. A make target is better here, partly because
>   make from clean (which is what debuild does) takes ages.
> 
> 3. Providing a minimalist install (e.g. without header files) of a
>   development build - i.e. a small 'package' to take over to another
>   machine to install for the purposes of testing - that's what
>   my minideb target did. Again a make target is better here.

Couldn't (3) be a part of (1)?  You'd have a set of packages (e.g. xen,
docs, tools, tools-dev) and only install the ones you need. 

Tim.

Re: [PATCH v2] tools: Improve make deb

[Alex Bligh]

Tim,

--On 1 March 2013 09:35:45 +0000 Tim Deegan <tim@xen.org> wrote:

>> 1. Providing some sort of debian packaging allowing the unstable build
>>   to be used and installed in a normal way, to encourage testing of
>>   unstable. This needs init scripts etc. in it, but typically the
>>   user isn't making his own changes. This should be debuild thing
>>   with a debian directory (in my opinion), and might not want to be
>>   upstream in a conventional way.
>>
>> 2. Providing a .deb for the developer, with a bit more functionality
>>   than the .tgz (e.g. not stomping on configuration files), and
>>   arguably some init files, but essentially to let the developer
>>   install his own stuff. A make target is better here, partly because
>>   make from clean (which is what debuild does) takes ages.
>>
>> 3. Providing a minimalist install (e.g. without header files) of a
>>   development build - i.e. a small 'package' to take over to another
>>   machine to install for the purposes of testing - that's what
>>   my minideb target did. Again a make target is better here.
>
> Couldn't (3) be a part of (1)?  You'd have a set of packages (e.g. xen,
> docs, tools, tools-dev) and only install the ones you need.

The main reasons why I didn't do (3) that way is that making a new
.deb using debuild etc. tends to apply lots of patches to the source,
and require building from clean. That isn't ideal if you are doing
development builds from git (case 3), where you want to use make.

-- 
Alex Bligh

Re: [PATCH v2] tools: Improve make deb

[Tim Deegan]

At 15:30 +0000 on 04 Mar (1362411057), Alex Bligh wrote:
> --On 1 March 2013 09:35:45 +0000 Tim Deegan <tim@xen.org> wrote:
> >>1. Providing some sort of debian packaging allowing the unstable build
> >>  to be used and installed in a normal way, to encourage testing of
> >>  unstable. This needs init scripts etc. in it, but typically the
> >>  user isn't making his own changes. This should be debuild thing
> >>  with a debian directory (in my opinion), and might not want to be
> >>  upstream in a conventional way.
> >>
> >>2. Providing a .deb for the developer, with a bit more functionality
> >>  than the .tgz (e.g. not stomping on configuration files), and
> >>  arguably some init files, but essentially to let the developer
> >>  install his own stuff. A make target is better here, partly because
> >>  make from clean (which is what debuild does) takes ages.
> >>
> >>3. Providing a minimalist install (e.g. without header files) of a
> >>  development build - i.e. a small 'package' to take over to another
> >>  machine to install for the purposes of testing - that's what
> >>  my minideb target did. Again a make target is better here.
> >
> >Couldn't (3) be a part of (1)?  You'd have a set of packages (e.g. xen,
> >docs, tools, tools-dev) and only install the ones you need.
> 
> The main reasons why I didn't do (3) that way is that making a new
> .deb using debuild etc. tends to apply lots of patches to the source,
> and require building from clean. That isn't ideal if you are doing
> development builds from git (case 3), where you want to use make.

Ah - for some reason I thought you were using the minideb on production
machines. 

So this comes down to three things [my opinions in brackets]:

Should we have a proper .deb package (or set of packages) build from the
unstable tree?  [Sure, if someone will volunteer to build and maintain
it.]

Should the debball special-case config files and init scripts? [I don't
think so.]

Do we need a 'mini' version of the debball? [I have no use for one, but
if people can agree on what gets cut -- what about stubdoms, pv-grub,
python and OCaml bindings, trace tools? -- it seems harmless, and 
is basically a 1-line diff to mkdeb to delete some files].

Cheers,

Tim.