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

[Alex Bligh <alex@xxxxxxxxxxx>]

--On 28 February 2013 10:51:38 +0000 George Dunlap 
<george.dunlap@xxxxxxxxxxxxx> 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

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