Bug#711193: Mark hardening-wrapper/includes as deprecated build-depends

["Thijs Kinkhorst" <thijs@debian.org>]

On Wed, June 5, 2013 18:26, Russ Allbery wrote:
> Thijs Kinkhorst <thijs@debian.org> writes:
>
>> Packages should not Build-Depend on either of these packages and their
>> functionality, but rather use the superior dpkg buildflags solution.
>> Attached patch accomplishes that packagers are warned when they
>> build-depend on one of these packages.
>
> Well, given that I have a package that Build-Depends on hardening-wrapper,
> I should probably reply here.  :)
>
> dpkg-buildflags is all fine and good if the upstream source lets you
> override compiler flags easily.  If, however, it doesn't,
> hardening-wrapper is much easier to deal with than trying to patch all the
> places in the upstream source where the compiler flags have to be changed
> and then updating that patch for various versions of upstream source.  In
> the case of openafs, this is a known bug that upstream is working on
> (slowly) by untangling the flags used to build the kernel module (which on
> platforms other than Linux cannot be user-tunable) and the flags used to
> build userspace, so doing the work to hack in Debian's flags in the
> meantime seems like a lot of wasted effort.
>
> What problem are you hoping to solve with this Lintian tag?

Hardening-wrapper/includes have existed as the solution for build
hardening before dpkg buildflags was introduced. Therefore, quite a lot of
packages adopted hardening-wrapper/includes and put them into their
Build-Depends. Now that dpkg buildflags is the agreed-upon superior
solution, it is better if they move to this solution if possible. The tag
would alert them of this fact, as would it signal new packages adding this
method (e.g. by copying it from another package).

There are still valid use cases, but as you say even there it's probably a
(known) bug in the build system that precludes the use of dpkg buildflags.
The packages themselves aren't going anywhere, it's just that there's a
large quantity of use that's most likely inertia. The valid use cases
could perhaps add an override?


Cheers,
Thijs