Fabio Fantoni writes ("[Xen-devel] [PATCH] tools: Improve make deb"):> tools: Improve make debI''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 nameWhy ?> - Add conffiles to manage main config files on package updateI 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.
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 nameWhy? 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 > +EOFCalling 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 >
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
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
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.
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.
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.
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.
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.