Re: /usr/share/info/dir.gz if install-info is installed

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

Sebastian Andrzej Siewior writes ("Re: /usr/share/info/dir.gz if install-info is installed"):
> Sounds reasonable. However sometimes package maintainer argueue that the
> policy says "clean build environment" and having package X intalled is
> no longer clean (thus I have a problem and buildds do not).

It would be nice if there were a way for the maintainer of a package
like install-info, which could be expected to (and is now known to)
cause misbuilds, to declare this problem.

Eg:

  Package: install-info
  Build-Lossages: install-info

  Package: python2.3-minimal
  Build-Lossages: python-version-detect

The result would be dpkg-checkbuilddeps failing like this:

  dpkg-checkbuilddeps: Probable build lossages, not mentioned in Build-Lossages-Permit:
  dpkg-checkbuilddeps:  package install-info causing install-info lossage
  dpkg-checkbuilddeps:  package python2.3-minimal causing python-version-detect lossage

If you had a package which doesn't do python version autodetection (eg
doesn't byte-compile) and doesn't mind what you have installed you
could say:

  Source: python-frobnicator
  Build-Lossages-Permit: python-version-detect

Probnably, mentioning a package by name (not by virtual package) (and
if applicable by matching version number) in Build-Depends should
cause that package's Build-Lossages to be ignored.

At the moment, a binary package can be:

  * In build-essential: implicitly Depends for all builds

  * Not in build-essential: "don't care" for naive source packages
     (ie sources which don't mention this package particularly)

My proposal provides the additional:

  * Declares Build-Lossages: equivalent to a declared 
     Build-Conflicts for all naive sources.  Sources which can
     tolerate this package (or must depend on it) 

This would be most useful for compatibility versions.  The user who
installs a compatibility library or otherwise knows what they're doing
can specify --ignore-lossages or something.

Would maintainers actually be willing to add such a field to their
package ?  There is no point in this if maintainers (eg of
install-info) are normally going to say "sorry the bug is in all the
other 100 packages, not in my package".

Ian.