This will be a long post about an interesting topic. (packaging related, not sure if it is interesting to everybody)

  1. Getting more involved in Debian
  2. Debian Perl team's repack.sh
  3. The problem is... (or just go to the technical details)
  4. Try to patch git-buildpackage
  5. Okay then patch uscan to handle repack.sh better
  6. What about adding native repack functionality to uscan?
    1. Try it for some perl packages
    2. Relevant reports from bugs.debian.org

Getting more involved in Debian

I had this idea of getting more involved in Debian. I use Perl already so I thought debian-perl can be a good place to start.

I am especially interested in Mojolicious as it is a great Perl web framework I like to use to create a web UI for accessing administrative tools (sysadmin related). libmojolicious-perl (the debian package) is more than half a year old in debian so I tried to update it to the newest upstream version. It is created in a special way as it has minified javascript removed.

Debian Perl team's repack.sh

The Debian Perl team created a tool for their own use as this happens with

  • many packages
  • has to be done every time a new upstream release becomes available

They have a nice documentation about packaging and repacking (removing undesired or undistributable parts):

I can create packages quite easily, but I tried to do it in a Debian way as this can also help the package maintainers. OTOH: using these standard tools worth it in the long run.

The problem is... (or just go to the technical details)

repack.sh is invoked by uscan from the watch file.

The problem is that the repacking mechanism interacts badly with git-buildpackage. git-import-orig --uscan imports the original package and not the one with some files removed. This is because uscan unaware that repack happened. However it is possible for git-import-orig to obtain this information from uscan output. Example:

% uscan --dehs
<dehs>
<package>libmojolicious-perl</package>
<debian-uversion>2.98+dfsg</debian-uversion>
<debian-mangled-uversion>2.98</debian-mangled-uversion>
<upstream-version>3.68</upstream-version>
<upstream-url>http://search.cpan.org/CPAN/authors/id/S/SR/SRI/Mojolicious-3.68.tar.gz</upstream-url>
<status>Newer version available</status>
<target>libmojolicious-perl_3.68.orig.tar.gz</target>
<messages>Successfully downloaded updated package Mojolicious-3.68.tar.gz and symlinked libmojolicious-perl_3.68.orig.tar.gz to it</messages>
<messages>Executing user specified script: sh debian/repack.stub --upstream-version 3.68 ../libmojolicious-perl_3.68.orig.tar.gz; output:

Repackaging ../libmojolicious-perl_3.68.orig.tar.gz

removed `lib/Mojolicious/public/js/jquery.js'
*** ../libmojolicious-perl_3.68+dfsg.orig.tar.gz ready</messages>
</dehs>

Try to patch git-buildpackage

The line which start with '***' contains the repacked filename so git-import-orig can learn about it! I submitted a patch for git-buildpackage (#635920). To tell the truth I know that this is not the best solution, but there was already an open bugreport and it seemed convenient.

Okay then patch uscan to handle repack.sh better

I was told to try fixing / enhancing uscan instead. So I added a special case if the invoked script is debian/repack.stub and asked Gregor Herrmann on #debian-perl. <git://cstamas.hu/git/devscripts.git>

He noted that he has doubts that adding a special case for repack is the right thing to do. I told him that uupdate is already handled special.

OTOH if repack.stub (this is what finds and executes the real repack.sh) is handled in a special way then if we want a robust interface repack should be included in devscripts (uscan is part of devscripts) We (Gregor Herrmann and me) agreed on this.

What about adding native repack functionality to uscan?

This was my next thinking: why stop there? just improve uscan to know about repack (there is already a repack command line switch in uscan, but that is just recompression nothing more now)

Gregor told me that this is something Andreas Tille has been working on #685787. Oh, well... I looked at it and it seemed entirely in the right direction just it wont happen before wheezy.

Now it is located in this git repo: <git://git.debian.org/git/users/tille/devscripts.git>

Try it for some perl packages

I tried how this can replace the already working functionality as used by the debian-perl team. I removed repack.stub from uscan's watch file. No more external commands as this is internal from now on. I also added the right paramenters to the copyright file. It is Files-Excluded see:

Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: Mojolicious
Upstream-Contact: Sebastian Riedel <sri@removed-intentionally>
Source: http://search.cpan.org/dist/Mojolicious/
Comment: jquery.js is removed (not the preferred form of modification)
 to create the +dfsg version.
Files-Excluded: lib/Mojolicious/public/js/jquery.js

This works quite well except that it still returns the original filename in the \<target> section :-/ I am about to file bugreports for this. When it is done:

  1. There will be a universal way of repacking packages in debian.
  2. The perl team can migrate to this new format
  3. As git-import-orig cares about the \<target> output of uscan it will just work without any change

Relevant reports from bugs.debian.org