dh_debputy - build Debian binary packages using debputy

       Niels Thykier <niels@thykier.net>

perl v5.40.1                                       2025-03-13                                      dh_debputy(1)

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).

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.

       dh_debputy - build Debian binary packages using debputy

       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:noand
       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
       behavior 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.

   Howtoensurethedpkg-debassemblymethodisbeingused
       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.

--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.

debhelper(7)

       This program integrates into the debhelper suite.

dh_debputy [debhelperoptions] [--destdir=directory] [--params]