Re: Build-Depends-Indep, please review
"Boyd Stephen Smith Jr." <bss@iguanasuicide.net> writes:
> In <[🔎] 20101120183255.GF12640@khazad-dum.debian.net>, Henrique de Moraes Holschuh
> wrote:
>>On Fri, 19 Nov 2010, Boyd Stephen Smith Jr. wrote:
>>> >But hey, all the maintainer has to do is add 1, in words ONE, char to
>>> >debian/rules. Just change "build:" to "build%:" and dpkg-buildpackage
>>> >could use build-arch/indep targets instead of build. Aparently that is
>>> >too much to ask.
>>>
>>> I volunteer to make /this/ fix to any package that is unmaintained or
>>> whose maintainer is unresponsive, *if* Debian will change policy to
>>> /require/ build- arch/indep and make dpkg-buildpackage use them instead
>>> of build sometime after the Squeeze release and before the Wheezy freeze.
>>
>>It can be done, but it must be done in at least two steps:
>>
>>1. Make it SHOULD, start fixing packages. You don't have to wait for the
>> SHOULD to start fixing packages, either.
>
> I'm not willing to manually test random packages for this breakage. What's
> the best way to get an automated process to report on the PTS or BTS the
> existence of build-arch and build-indep? Could it simply be a lintian test?
Setup an autobuilder, patch dpkg-buildpackage to call build-arch/indep,
rebuild all packages, read all failed build logs.
You could set up a lintian test that checks for a targets compatible
with build-arch/indep to get a fairly goo result. I.e. '%' is compatible,
'build%' is and so on. You will get some false positives and false
negatives but for a lintian test that should be ok. Unfortunately it
isn't good enough for dpkg-buildpackage use.
If you have the knowledge to write lintian tests then please do.
> Also, I thought it was already a SHOULD.
It is more a CAN. The targets are declared optional without a statement
one SHOULD have them even if they only depend on 'build'.
>>2. When almost everything is fixed, make it MUST. Whatever doesn't get
>> fixed after that, gets axed from the next stable.
>
> My time was volunteered (in my last posting) *after* it becomes a MUST, but
> with some help I might be willing to put some time in as part of a DEP.
And that is the problem. You will only do the work if you MUST. And you
only MUST if the work is almost done.
The same goes for maintainers accepting patches. There are a lot of
sources, maybe even the majority, where build-arch/indep is of no
use. And there maintainers are adverse to adding a patch for
build-arch/indep that is totaly useless (for their source).
Why not loosen your requirement a bit? For example would you volunteer
to NMU packages if build-arch/indep targets become a release goal for
wheeze?
MfG
Goswin
Reply to: