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
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 ourselvesAll the changes look good to me
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 meThis 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.
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?
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.
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.
--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
--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
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?
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.)
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.
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.
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.
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.
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.
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.
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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.
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
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? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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.
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
--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§ion=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
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.
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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.
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
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.
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
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.
Ian Jackson
2013-Feb-28 16:12 UTC
Re: [PATCH v2] tools: Improve make deb [and 1 more messages]
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.
--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
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.
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
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.