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.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/19600.52207.966968.858...@chiark.greenend.org.uk
