[ANNOUNCE] dh_splitpackage 0.2.2
zygmunt.krynicki at canonical.com
Sat Jun 4 20:56:24 UTC 2011
W dniu 04.06.2011 21:59, Benjamin Drung pisze:
> Am Samstag, den 04.06.2011, 20:46 +0200 schrieb Zygmunt Krynicki:
>> The new script can be called instead of dh_install (assuming all the
>> files you are interested in are already in debian/tmp/) or afterwards.
> I looked at the man page of dh_splitpackage and compared it to
> "dh_install --fail-missing". I found three differences. Please let me
> know if there were more.
There are two more differences:
1) dh_install is much more generic, dh_splitpackage cannot install files
from source directory. Only from debian/tmp. This is by design to keep
the same experience for developers and to focus the tool on only one thing.
2) dh_install reads multiple configuration files and is also used
directly in custom deban/rules overrides. dh_splitpackage is usable in
only one way, via a configuration file. The intent for this is the same
as above, to simplify the developer experience. It also limits the
number of configuration files that you need to create to one per source
> 1. dh_splitpackage complains if a file ends up in more than one binary
> package. Having the same file in two binary package leads to a conflict
> if you want to install both binary packages. IMO dh_install should do
> this check too.
> 2. dh_splitpackage put files in the primary package if no other install
> destination is specified. I would love to see a command line option for
> dh_install that does the same. For example, I want to call "dh_install
> --put-everything-else-in=vlc-nox" for the daily builds of vlc.
It only does this when explicitly requested by setting primary_package
in the configuration file. By default it just silently ignores those
files (silently as in not breaking the build, the build log indicates
this when printing pathname classification).
I can see it would be sensible to warn the packager that primary_package
was not specified and some pathnames were not classified. I'll add this
to next release.
> 3. dh_splitpackage supports more pattern than dh_install. To name them:
> ** for matching all directories,  to match as specific set of
> characters. I could live without that, but ** would be nice sometimes.
> I think that dh_install could be improved to support all three points
I would like to see that as well. I asked debhelper maintainer to have a
look at my helper and see what we can do.
> The features of dh_splitpackage are great, but the configuration format
> (JSON) seems to be too complex for this use case.
JSON was my initial attempt as I love it very much and is the best
general-purpose tree-like format that is still very easy to work with.
After looking at the examples I wrote I still like it but I see the
problem it could pose to packagers.
I could augment/replace the JSON format with a simple ini-style format.
Fortunately the configuration is very simple and could be mapped almost
$ cat debian/splitpackage
# Global configuration goes first.
# Here you can set the primary package
# Hypothetical new option that warns the packager
# when files are left unclassified. Possible options:
# ignore, fail.
# Classifiers for libfoo-dev. Pick up all the header files,
# libtool files, and static libraries
# Just for demonstration, never pick any shared objects
# Everything is automatically
# assigned by default thanks to
# primary_package in the global
More information about the ubuntu-devel