Re: Build-Depends-Indep: debhelper, utilizing it in debian/rules clean
Roland Stigge <email@example.com> wrote:
> Andreas Metzler wrote:
>> The main point was that your mail was suggesting that we might have
>> 1000 packages in Debian with a hidden FTBFS bugs and I wanted to reject
>> that, because bugs like #216747 will be found the first time the
>> package is autobuilt.
>>  Binary-all packages are not autobuilt, but if you build them you
>> will install both Build-Depends and Build-Depends-Indep anyway,
>> therefore it is no FTBFS but a cosmetical issue (not following policy
>> without any real harm).
> Exactly. "Build-Depends-Indep: debhelper" source packages tend to
> include "Architecture: all" binary packages.
s/tend to include/will only build/
because otherwise they would be grabbed by the autobuilders which
would have found and reported the bug as RC.
> So, the described bug seems to be quite popular, especially driven
> by lintian and linda, as noted by some.
> Which severity (if "serious" seems to be exaggerated here) would it be?
> Is it worthwhile to do at all? By following the thread, I guess not. But
> then we need to work on Policy. What about redefining
> Build-Depends-Indep by the implementation of buildds? ;-)
For "Architecture: all"-only packages where it does not generate a
FTBFS *imho* it is normal. A compromise between breaking policy
(serious) but having no practical consequences (minor).
OTOH if you can get a legal FTBFS, "serious". But I doubt you'd
find many of these.
Is evolution seriously broken or did you misconfigure it? The fact
that it does not generate References or In-Reply-To headers breaks
 dpkg-buildpackage without -d
Hey, da ist ein Ballonautomat auf der Toilette!
Unofficial _Debian-packages_ of latest unstable _tin_