Adding upstream version 13.11.4.upstream/13.11.4upstream

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 882 insertions, 0 deletions

diff --git a/dh b/dh
new file mode 100755
index 0000000..c1c511b
--- /dev/null
+++ b/dh
@@ -0,0 +1,882 @@
+#!/usr/bin/perl
+
+=head1 NAME
+
+dh - debhelper command sequencer
+
+=cut
+
+use strict;
+use warnings;
+use constant {
+	'UNSKIPPABLE_CLI_OPTIONS_BUILD_SYSTEM' => q(-S|--buildsystem|-D|--sourcedir(?:ectory)?|-B|--builddir(?:ectory)?),
+	'BUILD_STAMP_FILE'                     => 'debian/debhelper-build-stamp',
+};
+use Debian::Debhelper::Dh_Lib;
+use Debian::Debhelper::Sequence;
+use Debian::Debhelper::SequencerUtil;
+use Debian::Debhelper::DH::SequenceState ();
+
+our $VERSION = DH_BUILTIN_VERSION;
+
+=head1 SYNOPSIS
+
+B<dh> I<sequence> [B<--with> I<addon>[B<,>I<addon> ...]] [B<--list>] [S<I<debhelper options>>]
+
+=head1 DESCRIPTION
+
+B<dh> runs a sequence of debhelper commands. The supported I<sequence>s
+correspond to the targets of a F<debian/rules> file: B<build-arch>,
+B<build-indep>, B<build>, B<clean>, B<install-indep>, B<install-arch>,
+B<install>, B<binary-arch>, B<binary-indep>, and B<binary>.
+
+=head1 OVERRIDE AND HOOK TARGETS
+
+A F<debian/rules> file using B<dh> can override the command that is run
+at any step in a sequence, by defining an override target.  It is also
+possible to inject a command before or after any step without affecting
+the step itself.
+
+=head2 Injecting commands before or after a step
+
+I<Note>: This feature requires debhelper 12.8 or later plus the package must
+use compatibility mode 10 or later.
+
+To inject commands before I<dh_command>, add a target named
+B<execute_before_>I<dh_command> to the rules files.  Similarly, if you
+want to inject commands after I<dh_command>, add the target
+B<execute_after_>I<dh_command>.  Both targets can be used for the same
+I<dh_command> and also even if the command is overridden (as described in
+L</Overriding a command> below).
+
+When these targets are defined, B<dh> will call the targets respectively
+before or after it would invoke I<dh_command> (or its override target).
+
+=head2 Overriding a command
+
+To override I<dh_command>, add a target named B<override_>I<dh_command> to
+the rules file. When it would normally run I<dh_command>, B<dh> will
+instead call that target. The override target can then run the command with
+additional options, or run entirely different commands instead. See
+examples below.
+
+=head2 Architecture dependent/independent override and hook targets
+
+The override and hook targets can also be defined to run only
+when building architecture dependent or architecture independent
+packages. Use targets with names like B<override_>I<dh_command>B<-arch>
+and B<execute_after_>I<dh_command>B<-indep>.
+
+This feature is available since debhelper 8.9.7 (for override targets)
+and 12.8 (for hook targets).
+
+=head2 Completely empty targets
+
+As a special optimization, B<dh> will skip a target if it is
+completely empty and does not depend on any other target.  This is
+mostly useful for override targets, where the command will simply be
+skipped without the overhead of invoking a dummy target.
+
+Note that the target has to be completely empty for this to work:
+
+     # Skip dh_bar - the good and optimized way
+     # Some rationale for skipping dh_bar goes here
+     override_dh_bar:
+
+
+     # Skip dh_foo - the slow way
+     override_dh_foo:
+        # Some rationale for skipping dh_foo goes here
+        # (these comments causes a dummy target to be run)
+
+=head2 Verifying targets are picked up by dh
+
+As of debhelper 13.10, you can use L<dh_assistant(1)> to see which override
+and hook targets will be seen by B<dh>.  Here is an example run of L<dh_assistant(1)>
+along with its output:
+
+    $ dh_assistant detect-hook-targets
+    {
+       "commands-not-in-path": [
+          "dh_foo"
+       ],
+       "hook-targets": [
+          {
+             "command": "dh_strip_nondeterminism",
+             "is-empty": true,
+             "package-section-param": null,
+             "target-name": "override_dh_strip_nondeterminism"
+          },
+          {
+             "command": "dh_foo",
+             "is-empty": false,
+             "package-section-param": "-a",
+             "target-name": "override_dh_foo-arch"
+          }
+       ]
+    }
+
+The B<commands-not-in-path> is useful for spotting mistakes in the hook target
+names.  A non-empty value implies one of more hook targets are related to a command
+that is either not installed or no command with that name exists at all.  It is
+generally worth double checking these.
+
+Additionally, the B<is-empty> attribute for each hook target can be used for seeing
+whether a hook target triggers the L</Completely empty targets> optimization.
+
+If you are interested in the other attributes, please read the L<dh_assistant(1)>
+for the details.
+
+=head3 Verifying targets are picked up by dh (when debhelper is older than 13.10)
+
+
+
+On older versions of debhelper, you have to use B<dh> with B<--no-act>.
+You can use the following command as an example:
+
+    $ dh binary --no-act | grep dh_install | head -n5
+         dh_installdirs
+         dh_install
+         debian/rules execute_after_dh_install
+         dh_installdocs
+         dh_installchangelogs
+
+The B<debian/rules execute_after_dh_install> in the output, which signals
+that B<dh> registered a B<execute_after_dh_install> target and would
+run it directly after L<dh_install(1)>.
+
+Note that L</Completely empty targets> will be omitted in the listing above.
+This makes it a bit harder to spot as you are looking for the omission of
+a command name.  But otherwise, the principle remains the same.
+
+=head2 Caveats with hook targets and makefile conditionals
+
+If you choose to wrap a hook target in makefile conditionals, please
+be aware that B<dh> computes all the hook targets a head of time and
+caches the result for that run.  Furthermore, the conditionals will be
+invoked again when B<dh> calls the hook target later and will assume
+the answer did not change.
+
+The parsing and caching I<often> happens before B<dh> knows whether it
+will build arch:any (-a) or/and arch:all (-i) packages, which can
+produce confusing results - especially when L<dh_listpackages(1)> is
+part of the conditional.
+
+Most of the problems can be avoided by making the hook target
+unconditional and then have the "body" be partially or completely
+conditional.  As an example:
+
+      # SIMPLE: It is well-defined what happens.  The hook target
+      # is always considered.  The "maybe run this" bit is
+      # conditional but dh_foo is definitely skipped.
+      #
+      # Note: The conditional is evaluated "twice" where its
+      # influences what happens.  Once when dh check which hook
+      # targets exist and once when the override_dh_foo hook target
+      # is run.  If *either* times return false, "maybe run this"
+      # is skipped.
+      override_dh_foo:
+      ifneq (...)
+          maybe run this
+      endif
+
+      # SIMPLE: This is also well-defined.  The hook target is always
+      # run and dh_bar is skipped.  The "maybe run this" bit is
+      # conditional as one might expect.
+      #
+      # Note: The conditional is still evaluated multiple times (in
+      # different process each time).  However, only the evaluation
+      # that happens when the hook target is run influences what
+      # happens.
+      override_dh_bar:
+          : # Dummy command to force the target to always be run
+      ifneq (...)
+          maybe run this
+      endif
+
+
+      # COMPLICATED: This case can be non-trivial and have sharp edges.
+      # Use at your own peril if dh_listpackages in the conditional.
+      #
+      # Here, either dh_baz is run normally OR "maybe run this" is run
+      # instead.
+      #
+      # And it gets even more complicated to reason about if dh needs to
+      # recurse into debian/rules because you have an "explicit"
+      # standard target (e.g. a "build-arch:" target separate from "%:").
+      ifneq (...)
+      override_dh_baz:
+          maybe run this
+      endif
+
+These recipes are also relevant for conditional dependency targets,
+which are often seen in a variant of the following example:
+
+      COND_TASKS =
+      ifneq (...)
+      COND_TASKS += maybe-run-this
+      endif
+      ...
+
+      maybe-run-this:
+          ...
+
+      # SIMPLE: It is well-defined what happens.  Either the
+      # $(COND_TASKS) are skipped or run.
+      #
+      # Note: The conditional is evaluated "twice" where its
+      # influences what happens.  Once when dh check which hook
+      # targets exist and once when the override_dh_foo hook target
+      # is run.  If *either* times return false, $(COND_TASKS)
+      # is skipped.
+      override_dh_foo: $(COND_TASKS)
+
+
+      # SIMPLE: This is also well-defined.  The hook target is always
+      # run and dh_bar is skipped.  The $(COND_TASKS) bit is
+      # conditional as one might expect.
+      #
+      # Note: The conditional is still evaluated multiple times (in
+      # different process each time).  However, only the evaluation
+      # that happens when the hook target is run influences what
+      # happens.
+      override_dh_bar: $(COND_TASKS)
+          : # Dummy command to force the target to always be run
+
+      # COMPLICATED: This case can be non-trivial and have sharp edges.
+      # Use at your own peril if dh_listpackages in the conditional.
+      #
+      ifneq (...)
+      override_dh_baz: $(COND_TASKS)
+      endif
+
+
+When in doubt, pick the relevant B<SIMPLE> case in the examples above
+that match your need.
+
+=head1 OPTIONS
+
+=over 4
+
+=item B<--with> I<addon>[B<,>I<addon> ...]
+
+Add the debhelper commands specified by the given addon to appropriate places
+in the sequence of commands that is run. This option can be repeated more
+than once, or multiple addons can be listed, separated by commas.
+This is used when there is a third-party package that provides
+debhelper commands. See the F<PROGRAMMING> file for documentation about
+the sequence addon interface.
+
+A B<Build-Depends> relation on the package B<dh-sequence->I<addon>
+implies a B<--with> I<addon>. This avoids the need for an explicit
+B<--with> in F<debian/rules> that only duplicates what is already
+declared via the build dependencies in F<debian/control>.  The
+relation can (since 12.5) be made optional via e.g.
+build-profiles.  This enables you to easily disable an addon that
+is only useful with certain profiles (e.g. to facilitate
+bootstrapping).
+
+Since debhelper 12.5, addons can also be activated in B<indep>-only
+mode (via B<Build-Depends-Indep>) or B<arch>-only mode (via
+B<Build-Depends-Arch>). Such addons are only active in the particular
+sequence (e.g. B<binary-indep>) which simplifies dependency
+management for cross-builds.
+
+Please note that addons activated via B<Build-Depends-Indep> or
+B<Build-Depends-Arch> are subject to additional limitations to
+ensure the result is deterministic even when the addon is
+unavailable (e.g. during clean).  This implies that some addons
+are incompatible with these restrictions and can only be used via
+B<Build-Depends> (or manually via F<debian/rules>).  Currently,
+such addons can only add commands to sequences.
+
+=item B<--without> I<addon>
+
+The inverse of B<--with>, disables using the given addon. This option
+can be repeated more than once, or multiple addons to disable can be
+listed, separated by commas.
+
+=item B<--list>, B<-l>
+
+List all available addons.
+
+When called only with this option, B<dh> can be called from any
+directory (i.e. it does not need access to files from a source
+package).
+
+=item B<--no-act>
+
+Prints commands that would run for a given sequence, but does not run them.
+
+Note that dh normally skips running commands that it knows will do nothing.
+With --no-act, the full list of commands in a sequence is printed.
+
+=back
+
+Other options passed to B<dh> are passed on to each command it runs. This
+can be used to set an option like B<-v> or B<-X> or B<-N>, as well as for more
+specialised options.
+
+=head1 EXAMPLES
+
+To see what commands are included in a sequence, without actually doing
+anything:
+
+	dh binary-arch --no-act
+
+This is a very simple rules file, for packages where the default sequences of
+commands work with no additional options.
+
+	#!/usr/bin/make -f
+	%:
+		dh $@
+
+Often you'll want to pass an option to a specific debhelper command. The
+easy way to do with is by adding an override target for that command.
+
+	#!/usr/bin/make -f
+	%:
+		dh $@
+
+	override_dh_strip:
+		dh_strip -Xfoo
+
+	override_dh_auto_configure:
+		dh_auto_configure -- --with-foo --disable-bar
+
+Sometimes the automated L<dh_auto_configure(1)> and L<dh_auto_build(1)>
+can't guess what to do for a strange package. Here's how to avoid running
+either and instead run your own commands.
+
+	#!/usr/bin/make -f
+	%:
+		dh $@
+
+	override_dh_auto_configure:
+		./mondoconfig
+
+	override_dh_auto_build:
+		make universe-explode-in-delight
+
+Another common case is wanting to do something manually before or
+after a particular debhelper command is run.
+
+	#!/usr/bin/make -f
+	%:
+		dh $@
+
+	# Example assumes debhelper/12.8 and compat 10+
+	execute_after_dh_fixperms:
+		chmod 4755 debian/foo/usr/bin/foo
+
+If you are on an older debhelper or compatibility level, the above
+example would have to be written as.
+
+	#!/usr/bin/make -f
+	%:
+		dh $@
+
+	# Older debhelper versions or using compat 9 or lower.
+	override_dh_fixperms:
+		dh_fixperms
+		chmod 4755 debian/foo/usr/bin/foo
+
+Python tools are not run by dh by default, due to the continual change
+in that area. Here is how to use B<dh_python2>.
+
+	#!/usr/bin/make -f
+	%:
+		dh $@ --with python2
+
+Here is how to force use of Perl's B<Module::Build> build system,
+which can be necessary if debhelper wrongly detects that the package
+uses MakeMaker.
+
+	#!/usr/bin/make -f
+	%:
+		dh $@ --buildsystem=perl_build
+
+Here is an example of overriding where the B<dh_auto_>I<*> commands find
+the package's source, for a package where the source is located in a
+subdirectory.
+
+	#!/usr/bin/make -f
+	%:
+		dh $@ --sourcedirectory=src
+
+And here is an example of how to tell the B<dh_auto_>I<*> commands to build
+in a subdirectory, which will be removed on B<clean>.
+
+	#!/usr/bin/make -f
+	%:
+		dh $@ --builddirectory=build
+
+If your package can be built in parallel, please either use compat 10 or
+pass B<--parallel> to dh. Then B<dpkg-buildpackage -j> will work.
+
+	#!/usr/bin/make -f
+	%:
+		dh $@ --parallel
+
+If your package cannot be built reliably while using multiple threads,
+please pass B<--no-parallel> to dh (or the relevant B<dh_auto_>I<*>
+command):
+
+
+	#!/usr/bin/make -f
+	%:
+		dh $@ --no-parallel
+
+Here is a way to prevent B<dh> from running several commands that you don't
+want it to run, by defining empty override targets for each command.
+
+	#!/usr/bin/make -f
+	%:
+		dh $@
+
+	# Commands not to run:
+	override_dh_auto_test override_dh_compress override_dh_fixperms:
+
+A long build process for a separate documentation package can
+be separated out using architecture independent overrides.
+These will be skipped when running build-arch and binary-arch sequences.
+
+	#!/usr/bin/make -f
+	%:
+		dh $@
+
+	override_dh_auto_build-indep:
+		$(MAKE) -C docs
+
+	# No tests needed for docs
+	override_dh_auto_test-indep:
+
+	override_dh_auto_install-indep:
+		$(MAKE) -C docs install
+
+Adding to the example above, suppose you need to chmod a file, but only
+when building the architecture dependent package, as it's not present
+when building only documentation.
+
+	# Example assumes debhelper/12.8 and compat 10+
+	execute_after_dh_fixperms-arch:
+		chmod 4755 debian/foo/usr/bin/foo
+
+=head1 DEBHELPER PROVIDED DH ADDONS
+
+The primary purpose of B<dh> addons is to provide easy integration with
+third-party provided features for debhelper.  However, debhelper itself
+also provide a few sequences that can be useful in some cases.  These
+are documented in this list:
+
+=over 4
+
+=item build-stamp
+
+A special addon for controlling whether B<dh> (in compat 10 or later)
+will create stamp files to tell whether the build target has been run
+successfully. See L</INTERNALS> for more details.
+
+This addon is active by default but can disabled by using
+B<dh $@ --without build-stamp>
+
+=item dwz (obsolete)
+
+Adds L<dh_dwz(1)> to the sequence in compat level 11 or below.  Obsolete
+in compat 12 or later.
+
+=item elf-tools
+
+This addon adds tools related to ELF files to the sequence such as
+L<dh_strip(1)> and L<dh_shlibdeps(1)>
+
+This addon is I<conditionally> active by default for architecture
+specific packages - that is, it is skipped for arch:all packages.
+In the special case where you need these tools to work on arch:all
+packages, you can use B<--with elf-tools> to activate it
+unconditionally.
+
+=item installinitramfs (obsolete)
+
+Adds L<dh_installinitramfs(1)> to the sequence in compat level 11 or below.
+Obsolete in compat 12 or later.
+
+=item root-sequence (internal)
+
+This is reserved for internal usage.
+
+=item single-binary
+
+A special-purpose addon that makes debhelper run in "single binary" mode.
+
+When active, it will pass B<< --destdir=debian/I<package>/ >> to
+L<dh_auto_install(1)>.  This makes every file "installed" by the upstream
+build system part of the (only) binary package by default without having
+to use other helpers such as L<dh_install(1)>.
+
+The addon will refuse to activate when the source package lists 2 or more
+binary packages in F<debian/control> as a precaution.
+
+Before compat 15. this behaviour was the default when there was only a single
+binary package listed in F<debian/control>.  In compat 15 and later, this
+addon must explicitly be activated for this feature to work.
+
+The rationale for requiring this as an explicit choice is that if it is
+implicit then debhelper will silently change behaviour on adding a new
+binary package.  This has caused many RC bugs when maintainers renamed
+a binary and added transitional packages with the intention of supporting
+seamless upgrades.  The result would often be two empty binary packages that
+were uploaded to archive with users frustrated as their "upgrade" removed
+their programs.
+
+=item systemd (obsolete)
+
+Adds L<dh_systemd_enable(1)> and L<dh_systemd_start(1)> to the sequence in
+compat level 10 or below.  Obsolete in compat 11 or later.
+
+=back
+
+=head1 INTERNALS
+
+If you're curious about B<dh>'s internals, here's how it works under the hood.
+
+In compat 10 (or later), B<dh> creates a stamp file
+F<debian/debhelper-build-stamp> after the build step(s) are complete
+to avoid re-running them.  It is possible to avoid the stamp file by
+passing B<--without=build-stamp> to B<dh>.  This makes "no clean"
+builds behave more like what some people expect at the expense of
+possibly running the build and test twice (the second time as root or
+under L<fakeroot(1)>).
+
+Inside an override target, B<dh_*> commands will create a log file
+F<debian/package.debhelper.log> to keep track of which packages the
+command(s) have been run for.  These log files are then removed once
+the override target is complete.
+
+In compat 9 or earlier, each debhelper command will record
+when it's successfully run in F<debian/package.debhelper.log>. (Which
+B<dh_clean> deletes.) So B<dh> can tell which commands have already
+been run, for which packages, and skip running those commands again.
+
+Each time B<dh> is run (in compat 9 or earlier), it examines the log,
+and finds the last logged command that is in the specified
+sequence. It then continues with the next command in the sequence.
+
+A sequence can also run dependent targets in debian/rules.  For
+example, the "binary" sequence runs the "install" target.
+
+B<dh> uses the B<DH_INTERNAL_OPTIONS> environment variable to pass information
+through to debhelper commands that are run inside override targets. The
+contents (and indeed, existence) of this environment variable, as the name
+might suggest, is subject to change at any time.
+
+Commands in the B<build-indep>, B<install-indep> and B<binary-indep>
+sequences are passed the B<-i> option to ensure they only work on
+architecture independent packages, and commands in the B<build-arch>,
+B<install-arch> and B<binary-arch> sequences are passed the B<-a>
+option to ensure they only work on architecture dependent packages.
+
+=cut
+
+# Stash this away before init modifies it.
+my @ARGV_orig=@ARGV;
+my (@addons, @addon_requests);
+
+# Reset umask to 0022 per #944691
+umask(0022);
+
+init(options => {
+		"until=s" => \$dh{UNTIL},
+		"after=s" => \$dh{AFTER},
+		"before=s" => \$dh{BEFORE},
+		"remaining" => \$dh{REMAINING},
+		"with=s" => sub {
+			my ($option, $value) = @_;
+			push(@addon_requests, map { "+${_}" } split(",", $value));
+		},
+		"without=s" => sub {
+			my ($option, $value) = @_;
+			push(@addon_requests, map { "-${_}" } split(",", $value));
+		},
+		"l" => \&list_addons,
+		"list" => \&list_addons,
+	},
+	# Disable complaints about unknown options; they are passed on to
+	# the debhelper commands.
+	ignore_unknown_options => 1,
+	# Bundling does not work well since there are unknown options.
+	bundling => 0,
+	internal_parse_dh_sequence_info => 1,
+	inhibit_log => 1,
+);
+set_buildflags();
+reject_obsolete_params();
+
+# If make is using a jobserver, but it is not available
+# to this process, clean out MAKEFLAGS. This avoids
+# ugly warnings when calling make.
+if (is_make_jobserver_unavailable()) {
+	clean_jobserver_makeflags();
+}
+
+# Process the sequence parameter.
+my $sequence;
+if (! compat(7)) {
+	# From v8, the sequence is the very first parameter.
+	$sequence=shift @ARGV_orig;
+	if (defined $sequence && $sequence=~/^-/) {
+		error "Unknown sequence $sequence (options should not come before the sequence)";
+	}
+}
+else {
+	# Before v8, the sequence could be at any position in the parameters,
+	# so was what was left after parsing.
+	$sequence=shift;
+	if (defined $sequence) {
+		@ARGV_orig=grep { $_ ne $sequence } @ARGV_orig;
+	}
+}
+if (! defined $sequence) {
+	error "specify a sequence to run";
+}
+# make -B causes the rules file to be run as a target.
+# Also support completely empty override targets.
+# Note: it's not safe to use rules_explicit_target before this check,
+# since it causes dh to be run.
+if ($sequence eq 'debian/rules' ||
+    $sequence =~ /^override_dh_/ ||
+    $sequence =~ /^execute_(?:after|before)_dh_/ ||
+    $sequence eq DUMMY_TARGET) {
+	exit 0;
+}
+
+
+load_sequence_addon('root-sequence', SEQUENCE_TYPE_BOTH);
+
+
+sub list_addons {
+	my %addons;
+
+	for my $inc (@INC) {
+		require File::Spec;
+		my $path = File::Spec->catdir($inc, "Debian/Debhelper/Sequence");
+		if (-d $path) {
+			for my $module_path (glob "$path/*.pm") {
+				my $name = basename($module_path);
+				$name =~ s/\.pm$//;
+				$name =~ s/_/-/g;
+				next if $name eq 'root-sequence';
+				$addons{$name} = 1;
+			}
+		}
+	}
+
+	for my $name (sort keys %addons) {
+		print "$name\n";
+	}
+
+	exit 0;
+}
+
+
+# The list of all packages that can be acted on.
+my @packages=@{$dh{DOPACKAGES}};
+my @arch_packages = getpackages("arch");
+my @indep_packages = getpackages("indep");
+my %sequence2packages = (
+	'build-arch'   => \@arch_packages,
+	'install-arch' => \@arch_packages,
+	'binary-arch'  => \@arch_packages,
+
+	'build-indep'   => \@indep_packages,
+	'install-indep' => \@indep_packages,
+	'binary-indep'  => \@indep_packages,
+
+	'clean'   => \@packages,
+	'build'   => \@packages,
+	'install' => \@packages,
+	'binary'  => \@packages,
+);
+
+my $sequence_unpack_flags = 0;
+
+if ($sequence eq 'build-arch' ||
+    $sequence eq 'install-arch' ||
+    $sequence eq 'binary-arch') {
+	push(@Debian::Debhelper::DH::SequenceState::options, "-a");
+	# as an optimisation, remove from the list any packages
+	# that are not arch dependent
+	@packages = @{$sequence2packages{$sequence}};
+}
+elsif ($sequence eq 'build-indep' ||
+       $sequence eq 'install-indep' ||
+       $sequence eq 'binary-indep') {
+	push(@Debian::Debhelper::DH::SequenceState::options, "-i");
+	# ditto optimisation for arch indep
+	@packages = @{$sequence2packages{$sequence}};
+}
+
+if (not @arch_packages) {
+	$sequence_unpack_flags = FLAG_OPT_SOURCE_BUILDS_NO_ARCH_PACKAGES;
+} elsif (not @indep_packages) {
+	$sequence_unpack_flags = FLAG_OPT_SOURCE_BUILDS_NO_INDEP_PACKAGES;
+}
+
+@addons = compute_selected_addons($sequence, @addon_requests);
+
+# Load addons, which can modify sequences.
+foreach my $addon (@addons) {
+	my $addon_name = $addon->{'name'};
+	my $addon_type = $addon->{'addon-type'};
+	load_sequence_addon($addon_name, $addon_type);
+}
+
+if (%Debian::Debhelper::DH::SequenceState::commands_added_by_addon) {
+	while (my ($cmd, $addon) = each(%Debian::Debhelper::DH::SequenceState::commands_added_by_addon)) {
+		my $addon_type = $addon->{'addon-type'};
+		if ($addon_type eq 'indep') {
+			unshift(@{$Debian::Debhelper::DH::SequenceState::command_opts{$cmd}}, '-i');
+		} elsif ($addon_type eq 'arch') {
+			unshift(@{$Debian::Debhelper::DH::SequenceState::command_opts{$cmd}}, '-a');
+		}
+	}
+}
+
+
+if (! exists($Debian::Debhelper::DH::SequenceState::sequences{$sequence})) {
+	error("Unknown sequence $sequence (choose from: ".
+		join(" ", sort(keys(%Debian::Debhelper::DH::SequenceState::sequences))).")");
+}
+
+parse_dh_cmd_options(@ARGV_orig);
+
+_hoist_profile_into_dbo('nodoc');
+_hoist_profile_into_dbo('nocheck');
+
+if (is_cross_compiling() && !get_buildoption('nocheck') && !get_buildoption('crossbuildcanrunhostbinaries')) {
+	warning('Running tests during cross-builds is not supported in the general case (except for special cases or by');
+	warning('using emulation)');
+	warning('If the build fails, please consider rebuilding with DEB_BUILD_OPTIONS=nocheck.');
+	if (!is_build_profile_active('cross')) {
+		warning('Additionally, you might have to set the "cross" profile.  For dpkg-buildpackage, you do this by');
+		warning('passing the -Pcross option. Check the documentation of your build tool for how to set');
+		warning('DEB_BUILD_PROFILES if you use another build tool that does not auto-configure cross-building for you');
+	}
+	warning('If you have setup the relevant support for running cross-compiled binaries and want to silence this');
+	warning('warning, please use DEB_BUILD_OPTIONS=crossbuildcanrunhostbinaries')
+}
+
+# Figure out at what point in the sequence to start for each package.
+my (%logged, %startpoint, $completed_sequences);
+
+$completed_sequences = _check_for_completed_sequences(\%sequence2packages);
+
+# In compat <= 8, the sequences are always inlined (those versions do not
+# recurse into debian/rules anyway).  In compat 9+, we never inline an
+# existing rules target.
+my ($rules_targets, $full_sequence) = unpack_sequence(\%Debian::Debhelper::DH::SequenceState::sequences,
+														$sequence,
+														(!compat(8) ? 0 : 1),
+														$completed_sequences,
+														$sequence_unpack_flags,
+														);
+check_for_obsolete_commands($full_sequence);
+
+%startpoint = compute_starting_point_in_sequences(\@packages, $full_sequence, \%logged);
+
+for my $rules_command (@{$rules_targets}) {
+	my $rules_target = extract_rules_target_name($rules_command)
+		// error("Internal error: $rules_command was not a rules target!?");
+	# Don't pass DH_ environment variables, since this is
+	# a fresh invocation of debian/rules and any sub-dh commands.
+	delete($ENV{DH_INTERNAL_OPTIONS});
+	delete($ENV{DH_INTERNAL_OVERRIDE});
+	run_sequence_command_and_exit_on_failure("debian/rules", $rules_target);
+	my $override_packages = $sequence2packages{$rules_target} // \@packages;
+	for my $package (@{$override_packages}) {
+		my (undef, $seq) = unpack_sequence(\%Debian::Debhelper::DH::SequenceState::sequences, $rules_target, 1);
+		COMMAND: for my $c (reverse(@{$seq})) {
+			for my $j (0 .. $#{$full_sequence}) {
+				if ($c eq $full_sequence->[$j]) {
+					# Unfortunately, we do not guarantee any order
+					# between the run targets.  Assuming e.g.
+					# "install-arch" and "build" are opaque targets
+					# then we could process "install-arch" first and
+					# then "build".  In this case, it is important
+					# that we do not "reset" the starting point for
+					# "arch" packages.  Otherwise, we might repeat
+					# part of the "install-arch" sequence when we
+					# should not.
+					$startpoint{$package} = $j + 1 if $j + 1 > $startpoint{$package};
+					last COMMAND;
+				}
+			}
+		}
+	}
+}
+
+run_through_command_sequence($full_sequence, \%startpoint, \%logged,
+	\@Debian::Debhelper::DH::SequenceState::options,
+	\@packages, \@arch_packages, \@indep_packages);
+
+
+sub _check_for_completed_sequences {
+	my ($sequence2packages) = @_;
+	my (%completed, %stamp_file_content);
+	if ( -f BUILD_STAMP_FILE and not compat(9)) {
+		open(my $fd, '<', BUILD_STAMP_FILE) or error("open(${\BUILD_STAMP_FILE}, ro) failed: $!");
+		while (my $line = <$fd>) {
+			chomp($line);
+			$stamp_file_content{$line} = 1;
+		}
+		close($fd);
+		my $build_indep_target_done = 1;
+		my $build_arch_target_done = 1;
+		for my $pkg (@{$sequence2packages->{'build-arch'}}) {
+			if (not $stamp_file_content{$pkg}) {
+				$build_arch_target_done = 0;
+				last;
+			}
+		}
+		for my $pkg (@{$sequence2packages->{'build-indep'}}) {
+			if (not $stamp_file_content{$pkg}) {
+				$build_indep_target_done = 0;
+				last;
+			}
+		}
+		$completed{'build-arch'} = 1 if $build_arch_target_done;
+		$completed{'build-indep'} = 1 if $build_indep_target_done;
+		$completed{'build'} = 1 if $build_indep_target_done and $build_arch_target_done;
+	}
+	return \%completed;
+}
+
+
+sub reject_obsolete_params {
+	foreach my $deprecated ('until', 'after', 'before', 'remaining') {
+		if (defined $dh{uc $deprecated}) {
+			error("The --$deprecated option is not supported any longer (#932537). Use override targets instead.");
+		}
+	}
+}
+
+sub _hoist_profile_into_dbo {
+	my ($name) = @_;
+	if (is_build_profile_active($name) && !get_buildoption($name)) {
+		$ENV{'DEB_BUILD_OPTIONS'} //= '';
+		$ENV{'DEB_BUILD_OPTIONS'} .= ' ' . $name;
+		warning("Copying ${name} into DEB_BUILD_OPTIONS: It was in DEB_BUILD_PROFILES and but not in DEB_BUILD_OPTIONS");
+	}
+}
+
+=head1 SEE ALSO
+
+L<debhelper(7)>
+
+This program is a part of debhelper.
+
+=head1 AUTHOR
+
+Joey Hess <joeyh@debian.org>
+
+=cut