NAME

       dh_debputy - build Debian binary packages using debputy

SYNOPSIS

       dh_debputy [debhelper options] [--destdir=directory] [-- params]

DESCRIPTION

       dh_debputy is a tool for integrating debputy with debhelper as an interim solution until
       debputy covers enough features to be a standalone packaging tool.

       The debputy toolstack can built any deb without requiring root or fakeroot.  It is always
       possible to use Rules-Requires-Root: no with dh_debputy/debputy (given no non-debputy
       parts of debian/rules or the upstream build system require root).

OPTIONS

       --destdir=directory
           Use this if you want the generated .deb files to be put in a directory other than the
           default of "..".

       --plugin=name
           Have `debputy` load the given name.  The name can be a name, in which case the plugin
           must be installed into the proper plugin path (and in that case, you can often just
           have a build dependency on debputy-plugin-name ).

           Alternatively, the name can be a path (must contain / and should end with .json or
           .json.in).  In this case, that file is loaded as a plugin.  This case is useful for
           plugin providers to use their own plugin.

       -- params
           Pass params to dpkg-deb(1) when it is used to build the package.

           Restrict params to compression options as the dpkg-deb options may be emulated and not
           all of the dpkg-deb parameters are supported.

FILES

       debian/debputy.manifest
           Please see /usr/share/doc/dh-debputy/MANIFEST-FORMAT.md.gz.

           If you are converting your first package, you may want to read
           /usr/share/doc/dh-debputy/GETTING-STARTED-WITH-dh-debputy.md.gz first.

           Unlike most debhelper like tools, this file is per source package rather than per
           binary package.  Therefore, you cannot use debian/package.debputy.manifest to provide
           a specialized manifest for package.  Instead, all the needed parts should be written
           into the manifest itself.

ON DEB ASSEMBLY

       The dh_debputy will often use dpkg-deb for assembling the output. However, there are a few
       cases where dpkg-deb does not have the required features for 100% rootless assembly and
       debputy will use a different assembly method when needed.  Generally, this special-case
       only triggers with Rules-Requires-Root: no and when using a feature that requires root
       with dpkg-deb (such as static file ownership).

       If you experience, that a dh_debputy produced binary via its internal assembly method that
       is not 100% bit-for-bit reproducible with the equivalent root + dpkg-deb built deb and
       that is not caused by an inaccurate manifest in your end, please file a bug.  See the
       subsection "How to ensure the dpkg-deb assembly method is being used" for how you control
       which assembly method is being used.

       By producing exactly the same deb as dpkg-deb would have with fakeroot, we reduce the risk
       of bugs or bad behaviour during installation.

       Note that 100% bit-for-bit reproducible is not compared to debhelper.  Packages generated
       by debputy may differ from those built by debhelper. As an example, auto-generated shell
       snippets for maintainer scripts identifies the tool that generated them and it would be
       wrong for debputy to identify itself as debhelper in this case. This in turn creates a
       minor difference between packages generated by the two tools.  Consider using diffoscope
       to compare your debhelper generated deb to your debputy generated debs.

   How to ensure the dpkg-deb assembly method is being used
       The debputy tool stack has two assembly methods: dpkg-deb and the internal debputy method.

       By default, the dpkg-deb is used. The debputy tool will only switch to its internal method
       when:

       -   The package uses a feature that requires (fake)root when assembly via dpkg-deb. At the
           time of writing, this is only triggered by having static ownership in the deb (paths
           where ownership such as root:tty is recorded directly in the data.tar), AND

       -   The package does not run nor permit debputy to use (fake)root.  This part comes down
           to Rules-Requires-Root. When set to no, debputy will automatically fallback to the
           internal method as necessary.

           If you would like to avoid using root during package assembly but also do not want a
           custom assembly method, then you can set Rules-Requires-Root: debputy/deb-assembly and
           debputy will always use dpkg-deb for the assembly.  However, depending on your version
           of dpkg-dev you may run into #1036865 <https://bugs.debian.org/1036865>.  In that
           case, you will have to choose between using classic root (Rules-Requires-Root: binary-
           targets) or the internal rootless assembly method.

SEE ALSO

       debhelper(7)

       This program integrates into the debhelper suite.

AUTHOR

       Niels Thykier <niels@thykier.net>