From 129a1fb4dbc375be0fa926964aa1be46a0cdbbef Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Sun, 14 Apr 2024 21:54:34 +0200 Subject: Adding upstream version 0.1.21. Signed-off-by: Daniel Baumann --- dh_debputy | 175 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 175 insertions(+) create mode 100755 dh_debputy (limited to 'dh_debputy') diff --git a/dh_debputy b/dh_debputy new file mode 100755 index 0000000..4b9edee --- /dev/null +++ b/dh_debputy @@ -0,0 +1,175 @@ +#!/usr/bin/perl + +=encoding UTF-8 + +=head1 NAME + +dh_debputy - build Debian binary packages using debputy + +=cut + +use strict; +use warnings; +use Debian::Debhelper::Dh_Lib; + +our $VERSION = DH_BUILTIN_VERSION; + +=head1 SYNOPSIS + +B [S>] [B<--destdir=>I] [S I>] + +=head1 DESCRIPTION + +B is a tool for integrating B with debhelper as an interim solution +until B covers enough features to be a standalone packaging tool. + +The B toolstack can built I deb without requiring root or fakeroot. It is +always possible to use B with B/B (given no +non-debputy parts of F or the upstream build system require root). + +=head1 OPTIONS + +=over 4 + +=item B<--destdir=>I + +Use this if you want the generated F<.deb> files to be put in a directory +other than the default of "F<..>". + +=item B<--plugin=>I + +Have `debputy` load the given I. The I can be a name, in which case +the plugin must be installed into the proper plugin path (and in that case, you can +I just have a build dependency on B<< debputy-plugin-I >> ). + +Alternatively, the I can be a path (must contain B and should end with +B<.json> or B<.json.in>). In this case, that file is loaded as a plugin. This +case is useful for plugin providers to use their own plugin. + +=item B<--> I + +Pass I to L when it is used to build the +package. + +Restrict I to compression options as the B options may be +emulated and not all of the B parameters are supported. + +=back + +=head1 FILES + +=over 4 + +=item F + +Please see F. + +If you are converting your first package, you may want to read +F first. + +Unlike most debhelper like tools, this file is per source package rather than +per binary package. Therefore, you I use F<< debian/I.debputy.manifest >> +to provide a specialized manifest for I. Instead, all the needed parts +should be written into the manifest itself. + +=back + +=cut + +my (@plugins, $integration_mode); + +init(options => { + "destdir=s" => \$dh{DESTDIR}, + "plugin=s" => \@plugins, + "integration-mode=s" => \$integration_mode, +}); + +# Set the default destination directory. +if (! defined $dh{DESTDIR}) { + $dh{DESTDIR}='..'; +} + +my $debputy_cmd = $ENV{'DEBPUTY_CMD'} // 'debputy'; + +my @debputy_cmdline = ($debputy_cmd); +for my $plugin (@plugins) { + push(@debputy_cmdline, '--plugin', $plugin); +} +push(@debputy_cmdline, + 'internal-command', + 'dh-integration-generate-debs', +); +push(@debputy_cmdline, "--integration-mode=${integration_mode}") + if defined($integration_mode); +for my $package (@{$dh{DOPACKAGES}}) { + push(@debputy_cmdline, '-p', $package); +} +push(@debputy_cmdline, $dh{DESTDIR}); +if (@{$dh{U_PARAMS}}) { + push(@debputy_cmdline, '--', @{$dh{U_PARAMS}}); +} +doit(@debputy_cmdline); + +=head1 ON DEB ASSEMBLY + +The B will often use B for assembling the output. However, there are a few cases +where B does not have the required features for 100% rootless assembly and B will +use a different assembly method when needed. Generally, this special-case only triggers with +B I when using a feature that requires root with B (such as +static file ownership). + +If you experience, that a B produced binary via its internal assembly method that +is B 100% bit-for-bit reproducible with the equivalent B + B built deb +and that is not caused by an inaccurate manifest in your end, please file a bug. See the +subsection L for how you +control which assembly method is being used. + +By producing exactly the same deb as B would have with B, 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 B to compare your B generated deb to your B generated debs. + +=head2 How to ensure the dpkg-deb assembly method is being used + +The B tool stack has two assembly methods: B and the internal B method. + +By default, the B is used. The B tool will only switch to its internal method when: + +=over 4 + +=item - + +The package uses a feature that requires (fake)root when assembly via B. At the time of +writing, this is only triggered by having static ownership in the deb (paths where ownership such as +B is recorded directly in the F), AND + +=item - + +The package does not run nor permit B to use (fake)root. This part comes down to +B. When set to B, B 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 B and B +will always use B for the assembly. However, depending on your version of B +you may run into L<#1036865|https://bugs.debian.org/1036865>. In that case, you will have to +choose between using classic root (B) or the internal +rootless assembly method. + +=back + +=head1 SEE ALSO + +L + +This program integrates into the debhelper suite. + +=head1 AUTHOR + +Niels Thykier + +=cut -- cgit v1.2.3