[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#750576: ITP: debdry -- Semi-assisted automatic Debian packaging



Hi Enrico,

I'm not at Debconf, but heard of your debdry session and that way of
this ITP. (Actually Elmar, Cc'ed, made me aware of it.)

Enrico Zini wrote:
> The idea of debdry is to regenerate the debian/ directory every time a
> new version of the software is packaged, using the dh-make-equivalent
> for the given package type.

There are already packages in Debian which offer such functionality
for a specific subset of packages and which I think may help debdry to
reach its goal by not reinventing the part that's already there. :-)

I know at least of such functionality for Perl based packages (Cc'ing
the debian-perl list for that, too) in two flavours:

* dh-make-perl(*) has a subcommand refresh which refreshes the debian
  directory. For me, this works quite well with packages maintained in
  git. After a new upstream release, I run "dh-make-perl refresh" and
  then "git checkout -p" to review the changes it has done and then
  weed out the changes I don't need or want.

  One thing which is always added and then again removed by me, is the
  dh-make-perl disclaimer in debian/control. Despite this is a
  repetitive thing, I still think, it's not a bad thing, but debdry
  may want to remove that automatically again.

* dh-dist-zilla[1] exists since end of July and it's main purpose
  is to use Dist::Zilla[2]'s DRY features directly from your
  debian/rules so you don't need to commit the Dist::Zilla generated
  files to git (e.g. in a second just-for-debian upstream branch) if
  you're upstream and package maintainer in one person. With "dh $@
  --with dist-zilla", all debhelper needs is a dist.ini (and proper
  build-dependencies being installed) to build your .deb.

  [1] https://github.com/elmar/dh-dist-zilla
  [2] http://dzil.org/

  Since version 1.1, dh-dist-zilla also sports a dh-dzil-refresh
  command which combines the features of Dist::Zilla and "dh-make-perl
  refresh" to achieve the same as above, but with just having a
  dist.ini and no Makefile.PL or Build.PL yet.

  My long-term plan is to add dh-dist-zilla support to dh-make-perl,
  i.e. that dh-make-perl can cope with perl modules where upstream
  only provides a dist.ini but no Makefile.PL or Build.PL by making
  use of dh-dist-zilla.

> It then takes manually maintained data from
> the debian.in/ directory and uses it to complete the packaging.

For native or near-native (upstream = debian maintainer) packages
there also exists the idea of doing the opposite: Generating what is
needed for upstream setup tools based data in e.g. debian/control. In
the Perl world that would mean to generate dist.ini (preferably),
Makefile.PL or Build.PL based on data in debian/control.

> I have no intention of having debdry replace hand-writing debian/
> directories, nor have it handle all possible corner cases. I aim at it
> being useful in the general case. I want to address the ordinary,
> routine, boring work, and leave the rest as it is.

Sounds as if maintaining packages in git and "git checkout -p" again
would be a helpful add-on to the expected workflow. :-)

Looking forward to see this bird fly! :-)

Enrico wrote on debian-devel@l.d.o:
> Also, debdry is the first package that I have written that takes care
> of its own packaging :)

I don't see a debian.in directory in
http://anonscm.debian.org/cgit/collab-maint/debdry.git/tree/

So not sure where stuff came from when I ran "./debdry" in the git
checkout, but it did work to some extent. I was though surprised to
see a new "Standards-Version: 3.9.1" in the modified debian/control.
:-)

(*) After writing that, I saw that you already mention dh-make-perl in
    your README.md.

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-    |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5


Reply to: