| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| |
|
|
|
| |
Reason:
http://git.42mm.org/?p=python-greenlet;a=blob;f=debian/rules;h=bd009f86895d496999cd412eac44dbae7b9f1caa;hb=HEAD#l10
|
| | |
|
| |
|
|
| |
I see no reason to make this v9 only.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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. ]
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
override_dh_command-indep targets. This is needed when the binary target is run, rather than binary-arch/binary-indep. Closes: #648901
|
| | |
|
| |
|
|
| |
enough binutils and gdb; debhelper backport may need to disable this. Thanks, Aurelien Jarno and Bastien ROUCARIES. Closes: #631985
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Closes: 497653
|
| | |
|
| |
|
|
| |
#643702 Thanks, Steve Langasek.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
The standard way to pass build flags to makemaker perl build systems is to
set the OPTIMIZE variable on the commandline; CFLAGS in the environment gets
ignored entirely. So pass the CFLAGS from the environment to Makefile.PL so
makemaker packages can also benefit from dpkg-buildflags.
|
| | |
|
| | |
|
| |
|
|
| |
Closes: #643069
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
dirs. Closes: #641279
This is extra work, but querying dpkg-architecture for the multiarch lib
dir could easily take just as long.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
| |
A future nostripexceptonfullmoon option seems unlikely, but sure,
let's be strict. More importantly, let's reuse good code.
|
| | |
|
| |
|
|
| |
3.0 (quilt) is presumably better
|
| | |
|
| | |
|
| | |
|
| | |
|
