[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Build-Depends-Indep: debhelper, utilizing it in debian/rules clean

Roland Stigge <stigge@antcom.de> 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.[1]

>> [...]

>> [1] 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[1] 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
                  cu andreas
[1] dpkg-buildpackage without -d
Hey, da ist ein Ballonautomat auf der Toilette!
Unofficial _Debian-packages_ of latest unstable _tin_

Reply to: