| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
installed via symlinks. Closes: #721264
|
| |
|
|
| |
command that is now skipped creating the package build directory, the directory is created when a command is skipped. This workaround is disabled in compat level 10. Closes: #707336
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This is determined by the presence of special PROMISE directives within
commands that provide a high-level description of the command.
Note that when dh is passed additional debhelper options, it cannot tell if
these change the behavior of commands, and so it stops skipping any
commands.
|
| |
|
|
|
|
|
| |
avoid acting on packages covered by the override target when running the command for packages not covered by it. Closes: #676462
Hmm, this is technically a behavior change, but hopefully not one anything
could sanely depend on working like it used to.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
override_dh_command-indep targets. This is needed when the binary target is run, rather than binary-arch/binary-indep. Closes: #648901
|
| | |
|
| | |
|
| |
|
|
|
|
| |
has explicit binary-indep and binary-arch targets.
Closes: #639341 Thanks, Yann Dirson for test case.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* dh: Now you can use override_dh_command-arch and override_dh_command-indep
to run different overrides when building arch and indep packages. This
allows for a much simplified form of rules file in this situation, where
build-arch/indep and binary-arch/indep targets do not need to be manually
specified. See man page for examples.
* dh: Note that if a rules file has say, override_dh_fixperms-arch,
but no corresponding override_dh_fixperms-indep, then the unoverridden
dh_fixperms will be run on the indep packages.
* dh: Note that the old override_dh_command takes precidence over the new
overrides, because mixing the two types of overrides would have been
too complicated. In particular, it's difficult to ensure an
old override target will work if it's sometimes constrained to only
acting on half the packages it would normally run on. This would be
a source of subtle bugs, so is avoided.
|
| | |
|
| |
|
|
|
| |
Should be no behavior changes, although I did drop the comment when
skipping an empty override target.
|
| |
|
|
| |
3.0 (quilt) is presumably better
|
| | |
|
| |
|
|
|
|
|
| |
binary target when all packages being acted on are indep.
This is a not particularly interesting optimisation, but it will allow my
next commit..
|
| |
|
|
|
|
| |
To avoid re-breaking packages that were already broken a first time by
dpkg-buildpackage unconditionally setting the environment, and unbroke it
by unsetting variables in the rules file. (Example: numpy)
|
| |
|
|
| |
override targets instead.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
If a rules file has a custom install or binary target, those targets
still need to explicitly depend on the build target. Unless dh is used
in such a target (which it probably is of course).
It's not possible to avoid the need for those dependencies. A rules file
with a hand-written binary target simply does not run dh, so dh can
do nothing to help it run the build target.
Reword the docs to not give the wrong impression that dh somehow
magically makes that work.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
with a rules file with an explict build target. Closes: #634784
This hack was necessary back when dh ran each target, and so recursively
invoked itself. If debian/rules binary ran debian/rules binary-arch ran
debian/rules install-arch ran debian/rules build-arch, then debhelper
commands would be running with -a throughout, and so for debian/rules
binary-indep it would have to re-run all the commands with -i. The hack
avoided this extra work (and expecially dh_auto_configure running twice) by
first running the common commands without -i or -a and only then following
through with running the explicit per-arch targets, which didn't run many
(if any) additional commands.
But now dh does not run implicit targets, so (unless targets
are explicit), it will instead just construct a sequence of debhelper
commands to run directly, and so the -a flag is avoided.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
dh_pysupport has started emitting a deprecation warning, which is
very annoying since it clutters every build that uses dh -- even builds
where it doesn't do anything. Since there is not just a dh_python2, but
also a dh_python3 waiting in the wings, this is clearly too volatile
a situation for dh to try to support further.
I considered making dh_python detect and run the right dh_python[23] helper
-- a python helper helper as it were -- but 70-odd packages still use that
command.
|
| | |
|
| |
|
|
|
|
| |
This reverts commit fcfcd1298f6ea1fcfb2b2b5a529303270aa800d9.
Per Raphael's mail.
|
| |
|
|
|
|
| |
Do that even when dpkg-buildpackage modifies environment variables. Also
document DEB_${flag}_{APPEND,SET} as recommended way to override standard build
flags.
|
| |\
| |
| |
| |
| | |
Conflicts:
dh
|
| | |
| |
| |
| |
| |
| |
| |
| | |
* dh_auto_build, dh_auto_configure, dh: Set environment variables
listed by dpkg-buildflags --export. Any environment variables that
are already set to other values will not be changed.
Closes: #544844
* Also, support DEB_BUILD_OPTIONS=noopt, by changing -O2 to -O0.
|
| | |
| |
| |
| |
| | |
Appending @_ to a string appends the array length rather than
the array contents, so join with separating whitespace.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
The makefile parse causes dh to be run recursively.
Before, dh would just immediatly fail with "unknown sequence", but
now it has to run the makefile parse to calculate the sequences, so an
earlier bailout is needed.
|
| | |
| |
| |
| |
| |
| | |
An empty explicit target in debian/rules should still be run,
to run its dependencies, and allow defining empty targets in order to
skip running what's nornally done by a sequence.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
targets
This assumes that all implicit rules file targets are owned by dh, so
it can just assume an implicit target can be optimized away to the commands
in its sequence.
I suppose this would break:
build:
dh build
install: build
dh install
binary-%: install
my-binary-builder-$@
my-binary-builder-arch:
echo "whee! I did something pointlessly complicated with make!"
dh binary-arch
my-binary-builder-indep:
dh binary-indep
But I can't imagine anyone does this, at least with a probability of 1 in
ten thousand, so hopefully it doesn't break any existing packages. :)
|
| | |
| |
| |
| |
| |
| |
| | |
Reorder code so sequences can all be built before addons are loaded, so
addon interface can always affect all commands in any sequences. This fixes
a bug in the previous patch, where addons could not influence dh_testdir
and dh_testroot.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Callers overriding build targets will need to configure by hand or by
calling dh_auto_configure, which should be the status quo. And moving
dh_auto_configure to build (and build-arch and build-indep) will not
make it run twice AFAICS (except for the edge case when it already did:
debian/rules build-arch build-indep)
|
| | |
| |
| |
| |
| | |
These calls are no-ops, unless explicit targets exist, and in that case
later code rewrites the build and install sequences to include them.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The build and install rules run a minimal sequence if the build-arch or
build-indep, or install-arch or install-indep targets, respectively,
are present in debian/rules. The purpose is to not do work ahead of
time, such as building before the build-arch or build-indep targets are
built, which could potentially lead to misbuilds. If the targets are
not defined, the sequences may be run directly which is faster due to
being able to run the arch and indep commands together.
|
| |/
|
|
|
|
|
|
|
| |
Rather than dh sequences containing dependent sequences within
themselves, invoke the sub-sequence via debian/rules to permit
overriding and customisation using the policy-defined debian/rules
targets.
Signed-off-by: Roger Leigh <rleigh@debian.org>
|
| | |
|
| | |
|
| |
|
|
| |
#604727
|
