[PATCH] tools: Improve make deb

[PATCH] tools: Improve make deb

[Fabio Fantoni]

[-- Attachment #1.1.1: Type: text/plain, Size: 1511 bytes --]

# HG changeset patch
# User Fabio Fantoni
# Date 1335181425 -7200
# Node ID 98a2059a356e51416675f6d460ccd406aa8144e1
# Parent  b3375cbe809eb8398b75cd2b1590b957134e01f8
tools: Improve make deb
- Remove version from installed package name
- Add conffiles to manage main config files on package update
- Add/remove of main services (xencommons, xendomains)

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>

diff -r b3375cbe809e -r 98a2059a356e tools/misc/mkdeb
--- a/tools/misc/mkdeb    lun apr 23 10:26:55 2012 +0200
+++ b/tools/misc/mkdeb    lun apr 23 13:43:45 2012 +0200
@@ -33,7 +33,7 @@
  # 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
@@ -47,9 +47,27 @@
   the output of a xen "make dist" wrapped in a .deb to make it easy to
   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
+update-rc.d xendomains remove >/dev/null
+update-rc.d xencommons remove >/dev/null
+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


[-- Attachment #1.1.2: improve_make_deb.patch --]
[-- Type: text/plain, Size: 1492 bytes --]

# HG changeset patch
# User Fabio Fantoni
# Date 1335181425 -7200
# Node ID 98a2059a356e51416675f6d460ccd406aa8144e1
# Parent  b3375cbe809eb8398b75cd2b1590b957134e01f8
tools: Improve make deb
- Remove version from installed package name
- Add conffiles to manage main config files on package update
- Add/remove of main services (xencommons, xendomains)

Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>

diff -r b3375cbe809e -r 98a2059a356e tools/misc/mkdeb
--- a/tools/misc/mkdeb	lun apr 23 10:26:55 2012 +0200
+++ b/tools/misc/mkdeb	lun apr 23 13:43:45 2012 +0200
@@ -33,7 +33,7 @@
 # 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
@@ -47,9 +47,27 @@
  the output of a xen "make dist" wrapped in a .deb to make it easy to
  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
+update-rc.d xendomains remove >/dev/null
+update-rc.d xencommons remove >/dev/null
+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

[-- Attachment #1.2: Firma crittografica S/MIME --]
[-- Type: application/pkcs7-signature, Size: 4497 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] tools: Improve make deb

[Ian Jackson]

Fabio Fantoni writes ("[Xen-devel] [PATCH] tools: Improve make deb"):
> tools: Improve make deb

I'm rather unconvinced by this, in general.  The logical conclusion
would be for us to end up with machinery which attempts to make a
fully featured package.  I think this task is best left to a distro.

The "make deb" target is there to provide something convenient for
development and testing.

On to the individual changes:

> - Remove version from installed package name

Why ?

> - Add conffiles to manage main config files on package update

I would be inclined to take this if it were presented on its own.  The
effect can be useful during testing, and a dpkg purge will easily undo
it.

> - Add/remove of main services (xencommons, xendomains)

I think this is a bad idea, for the reasons I explain above.

Ian.

Re: [PATCH] tools: Improve make deb

[Ian Campbell]

On Mon, 2012-04-23 at 12:59 +0100, Fabio Fantoni wrote:
> # HG changeset patch
> # User Fabio Fantoni
> # Date 1335181425 -7200
> # Node ID 98a2059a356e51416675f6d460ccd406aa8144e1
> # Parent  b3375cbe809eb8398b75cd2b1590b957134e01f8
> tools: Improve make deb
> - Remove version from installed package name

Why? It seems to be common practice in Debian to include the version in
the package name for packages such as kernels and hypervisors.

> - Add conffiles to manage main config files on package update
> - Add/remove of main services (xencommons, xendomains)

I don't have any particular objection to doing this but I think we need
to be clear about what the purpose of Xen's "deb" target is.

It is intended as a convenience to developers (and perhaps some subset
of users), to allow them to do a reasonably clean "uninstall" of Xen
installed from source. It is not really intended to provide anything
more than that.

In particular the packages may not be fully policy compliant and we do
not plan to support things such as upgrades and the like. It also may
well be the case the installing the .deb is not sufficient to get a
working Xen system (i.e. you may still need to do much of the manual
configuration which is needed if you are building from source). If users
want a good, well supported package, well integrated, policy compliant
package for their distro then they should get it from the experts --
i.e. from the distro.

I'm just concerned that with these patches you may be trying to turn
this simple convenience functionality into something which you think is
suitable for end user consumption, which is something we need to think
carefully about since there is a maintenance (and expectation) burden
imposed by doing that.

> Signed-off-by: Fabio Fantoni <fabio.fantoni@heliman.it>
> 
> diff -r b3375cbe809e -r 98a2059a356e tools/misc/mkdeb
> --- a/tools/misc/mkdeb    lun apr 23 10:26:55 2012 +0200
> +++ b/tools/misc/mkdeb    lun apr 23 13:43:45 2012 +0200
> @@ -33,7 +33,7 @@
>   # 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
> @@ -47,9 +47,27 @@
>    the output of a xen "make dist" wrapped in a .deb to make it easy to
>    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
> +update-rc.d xendomains remove >/dev/null
> +update-rc.d xencommons remove >/dev/null
> +EOF

Calling inserv directly on install and update-rc.d on remove seems like
it is probably wrong. I suspect update-rc.d "add" is what you want.

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

Re: [PATCH] tools: Improve make deb

[George Dunlap]

On Tue, Apr 24, 2012 at 2:22 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> - Add conffiles to manage main config files on package update
>> - Add/remove of main services (xencommons, xendomains)
>
> I don't have any particular objection to doing this but I think we need
> to be clear about what the purpose of Xen's "deb" target is.
>
> It is intended as a convenience to developers (and perhaps some subset
> of users), to allow them to do a reasonably clean "uninstall" of Xen
> installed from source. It is not really intended to provide anything
> more than that.
>
> In particular the packages may not be fully policy compliant and we do
> not plan to support things such as upgrades and the like. It also may
> well be the case the installing the .deb is not sufficient to get a
> working Xen system (i.e. you may still need to do much of the manual
> configuration which is needed if you are building from source). If users
> want a good, well supported package, well integrated, policy compliant
> package for their distro then they should get it from the experts --
> i.e. from the distro.
>
> I'm just concerned that with these patches you may be trying to turn
> this simple convenience functionality into something which you think is
> suitable for end user consumption, which is something we need to think
> carefully about since there is a maintenance (and expectation) burden
> imposed by doing that.

I think in an ideal world, "make deb" (or "make rpm") would be used by
exactly the same people who at the moment do "make install" -- that
is, fairly technical end-users who have the knowledge to muck about
with their system; they need to take the responsibility to not shoot
themselves in the foot (or to bandage it up properly if they do).  I
think it's fairly likely that this will be the case, as long as we set
the expectations properly in the documentation and so on.

 -George

Re: [PATCH] tools: Improve make deb

[George Dunlap]

On Tue, Apr 24, 2012 at 2:46 PM, George Dunlap <dunlapg@umich.edu> wrote:
> On Tue, Apr 24, 2012 at 2:22 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>>> - Add conffiles to manage main config files on package update
>>> - Add/remove of main services (xencommons, xendomains)
>>
>> I don't have any particular objection to doing this but I think we need
>> to be clear about what the purpose of Xen's "deb" target is.
>>
>> It is intended as a convenience to developers (and perhaps some subset
>> of users), to allow them to do a reasonably clean "uninstall" of Xen
>> installed from source. It is not really intended to provide anything
>> more than that.
>>
>> In particular the packages may not be fully policy compliant and we do
>> not plan to support things such as upgrades and the like. It also may
>> well be the case the installing the .deb is not sufficient to get a
>> working Xen system (i.e. you may still need to do much of the manual
>> configuration which is needed if you are building from source). If users
>> want a good, well supported package, well integrated, policy compliant
>> package for their distro then they should get it from the experts --
>> i.e. from the distro.
>>
>> I'm just concerned that with these patches you may be trying to turn
>> this simple convenience functionality into something which you think is
>> suitable for end user consumption, which is something we need to think
>> carefully about since there is a maintenance (and expectation) burden
>> imposed by doing that.
>
> I think in an ideal world, "make deb" (or "make rpm") would be used by
> exactly the same people who at the moment do "make install" -- that
> is, fairly technical end-users who have the knowledge to muck about
> with their system; they need to take the responsibility to not shoot
> themselves in the foot (or to bandage it up properly if they do).  I
> think it's fairly likely that this will be the case, as long as we set
> the expectations properly in the documentation and so on.

[Remembering to cc everyone]

Is there a way to add a banner to the install / package description
saying something like, "Warning: This is a custom build of Xen; it is
not an officially supported Debian package.  Please do not
distribute."  Would that make sure no one is confused about the
resulting package?

 -George

Re: [PATCH] tools: Improve make deb

[Dario Faggioli]

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

On Tue, 2012-04-24 at 14:46 +0100, George Dunlap wrote: 
> On Tue, Apr 24, 2012 at 2:22 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > I'm just concerned that with these patches you may be trying to turn
> > this simple convenience functionality into something which you think is
> > suitable for end user consumption, which is something we need to think
> > carefully about since there is a maintenance (and expectation) burden
> > imposed by doing that.
> 
> I think in an ideal world, "make deb" (or "make rpm") would be used by
> exactly the same people who at the moment do "make install" -- that
> is, fairly technical end-users who have the knowledge to muck about
> with their system; they need to take the responsibility to not shoot
> themselves in the foot (or to bandage it up properly if they do).
>
I see and share Ian's feelings, but I agree with George. :-P
For what it counts, I happen to use kernel-package (make-kpkg) on Debian
systems to build my kernel because it's nice and easy tool to have
package(s) for my very own system.

Trying putting it the other way around, let's say I'd be sad if
make-kpkg weren't there, although I _never_ever_ wanted to distribute to
any kind of users the packages I produced with it.

Does this look close enough to this situation here? (If no, sorry for
the interference :-( ).

> I think it's fairly likely that this will be the case, as long as we set
> the expectations properly in the documentation and so on.
> 
Agreed  again.

Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 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] tools: Improve make deb

[Ian Campbell]

On Tue, 2012-04-24 at 14:46 +0100, George Dunlap wrote:
> On Tue, Apr 24, 2012 at 2:22 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> - Add conffiles to manage main config files on package update
> >> - Add/remove of main services (xencommons, xendomains)
> >
> > I don't have any particular objection to doing this but I think we need
> > to be clear about what the purpose of Xen's "deb" target is.
> >
> > It is intended as a convenience to developers (and perhaps some subset
> > of users), to allow them to do a reasonably clean "uninstall" of Xen
> > installed from source. It is not really intended to provide anything
> > more than that.
> >
> > In particular the packages may not be fully policy compliant and we do
> > not plan to support things such as upgrades and the like. It also may
> > well be the case the installing the .deb is not sufficient to get a
> > working Xen system (i.e. you may still need to do much of the manual
> > configuration which is needed if you are building from source). If users
> > want a good, well supported package, well integrated, policy compliant
> > package for their distro then they should get it from the experts --
> > i.e. from the distro.
> >
> > I'm just concerned that with these patches you may be trying to turn
> > this simple convenience functionality into something which you think is
> > suitable for end user consumption, which is something we need to think
> > carefully about since there is a maintenance (and expectation) burden
> > imposed by doing that.
> 
> I think in an ideal world, "make deb" (or "make rpm") would be used by
> exactly the same people who at the moment do "make install" -- that
> is, fairly technical end-users who have the knowledge to muck about
> with their system; they need to take the responsibility to not shoot
> themselves in the foot (or to bandage it up properly if they do).  I
> think it's fairly likely that this will be the case, as long as we set
> the expectations properly in the documentation and so on.

That seems reasonable, but much of the functionality being added here
isn't done by "make install", is it?

I'm not actually sure about the update-rc.d but the conf file handling
is clearly not part of "make install"

Ian.

Re: [PATCH] tools: Improve make deb

[Ian Campbell]

On Tue, 2012-04-24 at 14:56 +0100, George Dunlap wrote:
> On Tue, Apr 24, 2012 at 2:46 PM, George Dunlap <dunlapg@umich.edu> wrote:
> > On Tue, Apr 24, 2012 at 2:22 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >>> - Add conffiles to manage main config files on package update
> >>> - Add/remove of main services (xencommons, xendomains)
> >>
> >> I don't have any particular objection to doing this but I think we need
> >> to be clear about what the purpose of Xen's "deb" target is.
> >>
> >> It is intended as a convenience to developers (and perhaps some subset
> >> of users), to allow them to do a reasonably clean "uninstall" of Xen
> >> installed from source. It is not really intended to provide anything
> >> more than that.
> >>
> >> In particular the packages may not be fully policy compliant and we do
> >> not plan to support things such as upgrades and the like. It also may
> >> well be the case the installing the .deb is not sufficient to get a
> >> working Xen system (i.e. you may still need to do much of the manual
> >> configuration which is needed if you are building from source). If users
> >> want a good, well supported package, well integrated, policy compliant
> >> package for their distro then they should get it from the experts --
> >> i.e. from the distro.
> >>
> >> I'm just concerned that with these patches you may be trying to turn
> >> this simple convenience functionality into something which you think is
> >> suitable for end user consumption, which is something we need to think
> >> carefully about since there is a maintenance (and expectation) burden
> >> imposed by doing that.
> >
> > I think in an ideal world, "make deb" (or "make rpm") would be used by
> > exactly the same people who at the moment do "make install" -- that
> > is, fairly technical end-users who have the knowledge to muck about
> > with their system; they need to take the responsibility to not shoot
> > themselves in the foot (or to bandage it up properly if they do).  I
> > think it's fairly likely that this will be the case, as long as we set
> > the expectations properly in the documentation and so on.
> 
> [Remembering to cc everyone]
> 
> Is there a way to add a banner to the install / package description
> saying something like, "Warning: This is a custom build of Xen; it is
> not an officially supported Debian package.  Please do not
> distribute."  Would that make sure no one is confused about the
> resulting package?

tools/misc/mkdeb can inject whatever it likes into the description.

Ian.

Re: [PATCH] tools: Improve make deb

[Fantu]

Ian Jackson-2 wrote
> 
> Fabio Fantoni writes ("[Xen-devel] [PATCH] tools: Improve make deb"):
>> tools: Improve make deb
> 
> I'm rather unconvinced by this, in general.  The logical conclusion
> would be for us to end up with machinery which attempts to make a
> fully featured package.  I think this task is best left to a distro.
> 
> The "make deb" target is there to provide something convenient for
> development and testing.
> 
> On to the individual changes:
> 
>> - Remove version from installed package name
> 
> Why ?
> 
>> - Add conffiles to manage main config files on package update
> 
> I would be inclined to take this if it were presented on its own.  The
> effect can be useful during testing, and a dpkg purge will easily undo
> it.
> 
>> - Add/remove of main services (xencommons, xendomains)
> 
> I think this is a bad idea, for the reasons I explain above.
> 
> Ian.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@.xen
> http://lists.xen.org/xen-devel
> 
Yes, I know it's for development and testing, these small changes are
significant help.
The most important thing and that certainly no one would object to which the
management of configuration files, mantain configurations changes and report
any changes on the basic config do in development.
About package name it is correct to remove version from it, as is already on
his dedicated field and the creation of deb takes care of everything.
If version is mantained on package name any new version of the same package
will be treathed as differente one (not different version).
About services I added only basic, not all, I thought it was a good idea but
if not I will remove it

--
View this message in context: http://xen.1045712.n5.nabble.com/PATCH-tools-Improve-make-deb-tp5659234p5662227.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

Re: [PATCH] tools: Improve make deb

[Ian Jackson]

George Dunlap writes ("Re: [Xen-devel] [PATCH] tools: Improve make deb"):
> [Remembering to cc everyone]
> 
> Is there a way to add a banner to the install / package description
> saying something like, "Warning: This is a custom build of Xen; it is
> not an officially supported Debian package.  Please do not
> distribute."  Would that make sure no one is confused about the
> resulting package?

Yes, that would be straightforward and a good idea.  It should go into
the Description.

Ian.

Re: [PATCH] tools: Improve make deb

[Ian Jackson]

Ian Campbell writes ("Re: [Xen-devel] [PATCH] tools: Improve make deb"):
> On Tue, 2012-04-24 at 14:46 +0100, George Dunlap wrote:
...
> > I think in an ideal world, "make deb" (or "make rpm") would be used by
> > exactly the same people who at the moment do "make install" -- that
> > is, fairly technical end-users who have the knowledge to muck about
> > with their system; they need to take the responsibility to not shoot
> > themselves in the foot (or to bandage it up properly if they do).  I
> > think it's fairly likely that this will be the case, as long as we set
> > the expectations properly in the documentation and so on.
> 
> That seems reasonable, but much of the functionality being added here
> isn't done by "make install", is it?
> 
> I'm not actually sure about the update-rc.d but the conf file handling
> is clearly not part of "make install"

Arguably this is a bug in "make install".  The "make install" of many
other upstream projects completely fails to overwrite any existing
config files.

So I'm convinced that enabling dpkg's conffile handling for the config
files is the right thing to do.

However, the way this is done in Fabio's patch ...

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

... is not good.  We should mark as a conffile exactly every (plain)
file installed in /etc.  This should be done with a simple "find"
rune.

Having considered the ramifications, I'm also convinced that it is
correct for the package name to /not/ contain the version number.  The
key question from a dpkg semantics point of view is this: would it
ever make sense to coinstall two different versions ?  If it would
then they must have different names.  If not then they should not.

Now the packages made by "make deb" claim, entirely for themselves,
various paths.  Attempting to coinstall two of them is going to go
very badly: firstly a dpkg file conflict, and then if you override
that, a mess where you have mostly overwritten the old package but
parts of it remain.

So I think if you say "dpkg -i thing_i_just_built.deb" it should
replace the thing you installed previously with the new one.  The old
one is definitely not going to work any more anyway and any pieces
of it that remain are just luck.

Thanks,
Ian.