Re: [Xen-devel] [PATCH] tools: Improve make deb

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

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.

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