[Filesystems-devel] Bug#793863: Add new package f2fs-tools-dev for external development use

殷啟聰 seamlikok at gmail.com
Mon Nov 23 08:07:11 UTC 2015


Hi Vincent,

There are several reasons that dh-exec does simplify things,
especially when we are maintaining a package that produces multiple
binary packages:

  1. If you don't write *.install files, debhelper will install all
files under debian/tmp to the binary package with the same name of the
source package, i.e. "f2fs-tools".
  2. Without *.install or without specifying the install destination
in *.install, debhelper will try to guess what is the destination. The
way it uses is simply using the path text after "debian/tmp", so
either you don't use a *.install or the ${DEB_HOST_MULTIARCH} variable
must show up in the *.install files.
  3. All control files e.g. *.install can't use variables unless with
the support of dh-exec.
  4. One way to dropping the variables is to use wildcards, thus
"debian/tmp/${x86_64-linux-gnu}/libf2fs.so" can become
"debian/tmp/*/libf2fs.so", but seems wildcards don't work with
autodest because it failes on my machine.
  5. Even if wildcard + autodest works and we can get rid of dh-exec,
please look at f2fs-libs-dev.install and you can know we are
installing some files not under debian/tmp, whose install destinations
can't be guessed by dh_install, and we can't specify files with and
without install destination in a same *.install file.

So why not use dh-exec to make life simpler?

By the way I don't have access to collab-maint team, that's why I have
been posting patches rather than committing changes to SVN. Therefore
I can't be the co-maintainer for now although I wish to give a hand.
And I don't actually know what name should be given for the new binary
packages, can you think of better ones? :)

Regards,
Kai-Chung Yan



More information about the Filesystems-devel mailing list