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)
Joey Hess [Fri, 13 Aug 2010 15:58:25 +0000 (11:58 -0400)]
correct license of dh_installinit
It was GPL 2+ ; Steve added some code and chose to bump the license to GPL 3,
which is his right (and I don't mind), but that code is still mixed with
2+ code, which is now 3+.
Joey Hess [Sat, 7 Aug 2010 15:51:39 +0000 (11:51 -0400)]
python_distutils: Pass --force to setup.py build, to ensure that when python-dbg is run it does not win and result in scripts having it in the shebang line. Closes: #589759
Joey Hess [Sat, 7 Aug 2010 15:26:42 +0000 (11:26 -0400)]
Revert "python_distutils: Pass --force to setup.py build, to ensure that when python-dbg is run it does not win and result in scripts having it in the shebang line. Closes: #589759"
python_distutils: Pass --force to setup.py build, to ensure that when python-dbg is run it does not win and result in scripts having it in the shebang line. Closes: #589759
Joey Hess [Thu, 24 Jun 2010 00:40:16 +0000 (20:40 -0400)]
In v8 mode, stop passing packlist=0 in perl_makemaker buildsystem, since perl_build is tried first. Avoids the makemaker warning message introduced by the fix to #527990.
Joey Hess [Fri, 28 May 2010 19:16:52 +0000 (15:16 -0400)]
Revert "In v8 mode, debhelper only ever acts on packages that can be built for the given architecture, even if -N or -p are used to specify packages specific to other architectures."
Joey Hess [Fri, 28 May 2010 18:41:58 +0000 (14:41 -0400)]
In v8 mode, debhelper only ever acts on packages that can be built for the given architecture, even if -N or -p are used to specify packages specific to other architectures.
Joey Hess [Fri, 28 May 2010 01:16:26 +0000 (21:16 -0400)]
In v8 mode, dh expects the sequence to run is always its first parameter.
This avoids ambiguities when parsing options to be passed on to debhelper
commands. (See #570039)
In the end, the idea of putting the debhelper command options after --
seemed to need too much knowledge about whether an option like
--buildsystem is a dh option or a command option.
I did consider making no change.. The ambiguities this eliminates are
small. But it seemed worth simplifying dh's option parser, and only about
1/6th of calls to dh in the archive don't put the sequence first already.
(Docs have shown that as the right thing to do for some time.)
Happily, the way that was written, if the command doesn't exist,
it does the right thing and enables the behavior for the new debhelper.
Not that it would greatly matter if it did not, since --parallel is not
crucial.
Joey Hess [Sun, 23 May 2010 23:26:41 +0000 (19:26 -0400)]
In v8 mode, dh_makeshlibs will run dpkg-gensymbols on all shared libraries it generates shlibs files for. This means that -X can be used to exclude libraries from processing by dpkg-gensymbols. It also means that libraries in unusual locations, where dpkg-gensymbols does not itself normally look will be passed to it, a behavior change which may break some packages. Closes: #557603
Joey Hess [Tue, 18 May 2010 16:30:06 +0000 (12:30 -0400)]
dh_installman: Avoid converting .so links to symlinks if the link target is not present in the same binary package, on advice of Colin Watson. (To support eventual so search paths.)
Joey Hess [Sun, 9 May 2010 16:21:12 +0000 (12:21 -0400)]
Further reduce the number of calls to dpkg-architecture to zero, in a typical package with no explicit architecture mentions in control file or debhelper config files.
Memoize architecture comparisons in samearch, and avoid calling dpkg-architecture at all for simple comparisons not involving architecture wildcards. Closes:# 579317
projects / debhelper.git / log