summaryrefslogtreecommitdiff
path: root/debhelper.pod
Commit message (Collapse)AuthorAge
* Improve -X documentation. Closes: #686696Joey Hess2012-09-04
|
* Fix “compatab*” vs. “compatib*” typos.Cyril Brulebois2012-04-01
|
* Fix a typo in debhelper.podAntonio Ospite2012-03-26
| | | | Closes: #665891
* releasing version 9.20120311Joey Hess2012-03-11
|
* remove noopt mentionJoey Hess2012-03-01
| | | | | debhelper used to have its own noopt handling, but this was replaced by dpkg-buildflags doing it
* move build depends section into compat sectionJoey Hess2012-01-15
|
* updateJoey Hess2012-01-15
|
* v9 doneJoey Hess2012-01-15
| | | | | | | | * Finalized v9 mode, which is the new recommended default. (But continuing to use v8 is also fine.) * It is now deprecated for a package to not specify a compatability level in debian/compat. Debhelper now warns if this is not done, and packages without a debian/compat will eventually FTBFS.
* Typo. Closes: #653006Joey Hess2011-12-22
|
* Only enable executable config files in v9. The quality of file permissions ↵Joey Hess2011-12-09
| | | | in debian/ directories turns out to be atrocious; who knew?
* only v9Joey Hess2011-12-08
| | | | | Reason: http://git.42mm.org/?p=python-greenlet;a=blob;f=debian/rules;h=bd009f86895d496999cd412eac44dbae7b9f1caa;hb=HEAD#l10
* executable config files. bleh, arghJoey Hess2011-12-07
| | | | | | | | | | | | | | | | | | Debhelper config files may be made executable programs that output the desired configuration. No further changes are planned to the config file format; those needing powerful syntaxes may now use a programming language of their choice. In many bugs I see a tendency of users wanting debhelper configuration files to have their pet feature from some programming language. So I choose to short-circuit this process by taking it to its logical conclusion, and without the bother of developing a new language myself. [ Is this consistent with my boycott/disinterest in integrating features features first developed in Ubuntu? Yes. Instead of blocking the issue of multiarch needing variable expansions, I have stepped back and let anyone make whatever mess they desire while not forcing that mess on the rest of us. ]
* dh_strip: In v9, pass --compress-debug-sections to objcopy. Needs a new ↵Joey Hess2011-11-07
| | | | enough binutils and gdb; debhelper backport may need to disable this. Thanks, Aurelien Jarno and Bastien ROUCARIES. Closes: #631985
* updateJoey Hess2011-09-30
|
* update v9 docsJoey Hess2011-09-29
|
* updateJoey Hess2011-09-26
|
* Mention in debhelper(7) that buildsystem options are typically passed to dh. ↵Joey Hess2011-09-26
| | | | Closes: #643069
* wordingJoey Hess2011-09-08
|
* dpkg-buildflags is only used to set environment in v9Joey Hess2011-08-06
| | | | | | 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)
* doc tweak re target dependenciesJoey Hess2011-07-19
| | | | | | | | | | | | | 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.
* reorg notes sectionJoey Hess2011-07-16
|
* dh: In v9, do not enable any python support commands.Joey Hess2011-07-16
| | | | | | | | | | | | 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.
* typoJoey Hess2011-07-09
|
* Typo fixes. Closes: #632662Joey Hess2011-07-04
|
* Correct docs about multiarch and v9. Closes: #630826Joey Hess2011-06-17
|
* Merge branch 'master' into smarter-targetsJoey Hess2011-06-14
|\ | | | | | | | | Conflicts: dh
| * dpkg-buildflags supportJoey Hess2011-06-14
| | | | | | | | | | | | | | | | * 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.
* | Merge branch 'master' into smarter-targetsJoey Hess2011-06-14
|\| | | | | | | | | | | Conflicts: debhelper.pod debian/changelog
| * dh_auto_configure: In v9, does not include the source package name in ↵Joey Hess2011-06-14
| | | | | | | | | | | | | | --libexecdir when using autoconf. Closes: #541458 Fixed rleigh's patch to be more correct in the edge case where there is a non-multiarch dpkg (ie, backports).
* | make standard targets support a v9 featureJoey Hess2011-06-13
|/
* reorder v9 section and add missing =backJoey Hess2011-04-05
|
* Depend on dpkg-dev (>= 1.16.0) for multiarch support.Joey Hess2011-03-12
| | | | | | Note to backporters: If you remove that dependency, debhelper will fall back to not doing multiarch stuff in v9 mode, which is probably what you want.
* documentationJoey Hess2011-03-12
|
* typoJoey Hess2011-02-26
|
* Apply manual pages conventionsDavid Prévot2010-11-02
| | | | | | | | | As advised in man(1), always use: B<bold text> type exactly as shown. I<italic text> replace with appropriate argument. s/debian/Debian/ if needed. s/ / / also. s/perl/Perl/ s/python/Python/ and s/emacs/Emacs/ too.
* Finalized v8 mode, which is the new recommended default.Joey Hess2010-08-07
|
* In v8 mode, prefer the perl_build buildsystem over perl_makemaker. Closes: ↵Joey Hess2010-05-28
| | | | #578805
* exampleJoey Hess2010-05-27
|
* consistently use v7 not V7 (etc)Joey Hess2010-05-27
|
* In v8 mode, dh expects the sequence to run is always its first parameter.Joey Hess2010-05-27
| | | | | | | | | | | | | | 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.)
* In v8 mode, dh_makeshlibs will run dpkg-gensymbols on all shared libraries ↵Joey Hess2010-05-23
| | | | 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
* In v8 mode, do not allow directly passing unknown options to debhelper ↵Joey Hess2010-05-23
| | | | commands. (Unknown options in DH_OPTIONS still only result in warnings.)
* update Package-Type docsJoey Hess2010-05-23
| | | | dpkg supports the field now, so no XC- needed
* solve the dh -Bbuild problemJoey Hess2010-01-04
| | | | | | | | | * Add -O option, which can be used to pass options to commands, ignoring options that they do not support. * dh: Use -O to pass user-specified options to the commands it runs. This solves the problem with passing "-Bbuild" to dh, where commands that do not support -B would see a bogus -u option. Closes: #541773 (It also ensures that the commands dh prints out can really be run.)
* changelog and doc rewordingJoey Hess2009-12-07
|
* Add --parallel option.Modestas Vainius2009-12-04
| | | | | | | | | This patch adds --parallel option that enables parallel builds and does not impose limits on maximum concurrent processes. --max-parallel (that implies --parallel) can be used to specify that maximum limit. Also make necessary adjustments to debhelper.pod and buildsystem_tests for this option.
* Parallel building support is no longer enabled by default. It can still be ↵Joey Hess2009-11-23
| | | | enabled by using the --max-parallel option. This was necessary because some buildds build with -j2 by default.
* Drop deprecated programs from the list of commands in debhelper(7). Closes: ↵Joey Hess2009-11-04
| | | | #548382
* --max-parallel requires a numberJoey Hess2009-11-04
|
* implement the other option: parallel enabled implicitly by DEB_BUILD_OPTIONSJoey Hess2009-10-29
| | | | | I renamed --parallel to --max-parallel to clarify that it doesn't enable parallelism, but only controls how much of it is allowed.