Modestas Vainius [Sun, 19 Jun 2011 20:53:14 +0000 (23:53 +0300)]
Always respect DEB_${flag}_{APPEND,SET} envvars.
Do that even when dpkg-buildpackage modifies environment variables. Also
document DEB_${flag}_{APPEND,SET} as recommended way to override standard build
flags.
Modestas Vainius [Sat, 18 Jun 2011 20:02:42 +0000 (23:02 +0300)]
Use Dpkg::BuildFlags module directly in set_buildflags().
Dpkg::BuildFlags API is declared stable. It should be safe to use it directly
rather than dpkg-buildflags wrapper. In addition, do not do any
DEB_BUILD_OPTIONS=noopt handling in debhelper. Dpkg::BuildFlags already does it
for us.
Joey Hess [Tue, 14 Jun 2011 21:22:34 +0000 (17:22 -0400)]
dpkg-buildflags support
* 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.
Joey Hess [Tue, 14 Jun 2011 16:24:31 +0000 (12:24 -0400)]
avoid infinite recursion
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.
Joey Hess [Mon, 13 Jun 2011 23:13:32 +0000 (19:13 -0400)]
honor empty targets
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.
Joey Hess [Mon, 13 Jun 2011 21:00:08 +0000 (17:00 -0400)]
inline sequences to optimize away recursive calls to make/dh for implicit 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. :)
Joey Hess [Mon, 13 Jun 2011 20:41:21 +0000 (16:41 -0400)]
improve sequence logic
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.
Joey Hess [Mon, 13 Jun 2011 20:14:59 +0000 (16:14 -0400)]
move dh_auto_configure out of @bd_minimal
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)
Roger Leigh [Sun, 12 Jun 2011 19:22:43 +0000 (20:22 +0100)]
dh: Use minimal sequences if delegating work
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.
Roger Leigh [Fri, 3 Jun 2011 19:41:30 +0000 (20:41 +0100)]
dh: Add sequence dependency support
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.
Here is a patch against the master branch that adds such a command
called dh_installucf. It also registers the conffiles with ucfr and
removes stray ucf-{new,old,dist} files on purge.
dh_clean: Remove debhelper logs for all packages, including packages not being acted on. dh can sometimes produce such logs by accident when passed bundled options (like "-Nfoo" instead of "-N foo") that it does not understand; and it was not possible to fix that for any compat level before v8. But also, such logs can occur for other reasons, like interrupted builds during development, and it should be safe to clean them all. Closes: #623446
Steve Langasek [Fri, 11 Mar 2011 06:28:24 +0000 (22:28 -0800)]
Add support for multiarch.
Open compat level 9, which incompatibly changes dh_auto_configure behavior
to set --libdir and --libexecdir to the multiarch directory path. This
requires dpkg-dev 1.16.0 (not yet released) for the multiarch directory
variable, so bump the dependency to this version.
Also set a new substvar, misc:Pre-Depends, to multiarch-support, a virtual
package provided by versions of eglibc that support the multiarch library
paths at runtime; this needs to be a pre-dependency to ensure unpacked but
not-yet-configured libraries can still be found during upgrades, so library
packages converting to multiarch (i.e., switching to compat 9) will need to
add this substitution by hand to debian/control.
Joey Hess [Sun, 27 Feb 2011 19:44:10 +0000 (15:44 -0400)]
dh_auto_clean: Inhibit logging, so that, if dh_auto_clean is used in some rule other than clean, perhaps to clean up an intermediate build before a second build is run, debian/rules clean still runs it. Closes: #615553
Now all debhelper commands run in the override target are marked as running
as part of the override, and when the whole target is run, the log is
updated to indicate that commands run during the override have finished.
So, inside the override target, --remaining-packages will see the commands
run as part of the target as having been run. Outside, if the target
fails, dh won't see the commands run it it as having been run.
Joey Hess [Tue, 25 Jan 2011 21:13:21 +0000 (17:13 -0400)]
remove MODULEBUILDRC override
This doesn't work reliably, see #607313.
Probably that is caused by the perl_build buildsystem not being detected
for a package that has a Makefile.PL, and so MODULEBUILDRC is not
overridden. So, I could add it there too, but then it's also possible for
it to be run from a Makefile.. so I could add it to dh_auto_*. But
then there are packages that don't use those. So I conclude that dealing
with this in debhelper is out of its scope, and this needs to be fixed
at a higher level, probably dpkg-dev.
Roger Leigh [Tue, 23 Nov 2010 18:00:06 +0000 (18:00 +0000)]
dh: Add sequence dependencies and satisfy dependencies prior to running sequence
Add %sequence_deps and invoke recursively prior to examining logs and
running commands in sequence. The supplied dependencies are equivalent
to the following make rules:
In the existing dh command sequences, the binary sequences all included
the corresponding install sequence commands, and in turn the install
sequences all included the corresponding build commands. While this
works, it has a major deficiency. If the "binary" sequence is run, it
will not run the "build" target in debian/rules. This leads to a
situation where building with dpkg-buildpackge, which would typically
invoke "debian/rules build" followed by "debian/rules binary-arch"
and/or "debian/rules debian-indep" may do something different than
just invoking "debian/rules binary" or "dh binary" because the build
target in debian/rules is effectively bypassed. This applies equally
to the -arch and -indep sequence variants.
This change eliminates the duplicated sequence commands, and instead
invokes the appropriate target(s) in debian/rules, as specified in the
%sequence_deps hash. In the common case, the dh sequence by the same
name will be called, so the behaviour is identical. However, this
provides a means to utilise all of the policy-specified targets, plus
the install targets and extend them with additional dependencies and
commands, while still allowing full use of dh and giving identical
behaviour whether dh or debian/rules targets are used.
Roger Leigh [Mon, 22 Nov 2010 21:03:24 +0000 (21:03 +0000)]
dh: Use $(filter) rather than $(findstring)
$(findstring) can match partial strings and so is unreliable when a
package builds several binary packages and one package contains the
name of another package within its name. In these cases,
$(findstring) can return a partial match which leads to problems
(performing unwanted actions which could lead to build failure, for
example).
$(filter) matches the entire string in the wordlist, so is a
reliable replacement for $(findstring).
Joey Hess [Wed, 3 Nov 2010 02:48:01 +0000 (22:48 -0400)]
dh: Inhibit logging for commands run inside override targets
Note that only the overridden command is inhibited. I wanted to avoid a
behavior change if a rules file runs other debhelper commands inside the
target, and relies on the logging preventing them being run later on in
the sequence.
Joey Hess [Tue, 2 Nov 2010 20:24:04 +0000 (16:24 -0400)]
maintscript files
dh_installdeb: Support debian/package.maintscript files, which can contain
dpkg-maintscript-helper commands. This can be used to automate moving or
removing conffiles, or anything added to dpkg-maintscript-helper later on. Closes: #574443 (Thanks, Colin Watson)
projects / debhelper.git / log