Re: suggestion: build-blockers field in control file
* peter green <firstname.lastname@example.org>, 2011-11-29, 19:23:
Some packages have runtime dependencies on packages that they do not
have corresponding build-dependencies for. This leads to the building
of uninstallable packages which in turn leads to problems with
testing transition of packages.
Currently there are two workarounds for this situation
1: manually alter the package's architecture list to limit building
to those architectures where runtime dependencis
2: add an artificial build-dependency
Neither is ideal, the first must be manually undone if and when the
dependencies do become available. The second is an abuse of the
build-depends field (the package isn't REALLY needed for building)
and causes pacakges to be unnessacerally installed in build
environments (both on autobuilders and for those manually building
the package) wasting time and network bandwidth.
I therefore propose a new control field for source packages
"build-blockers". Autobuilder management systems should generally
treat build-blockers the same as build-depends but the systems that
actually do the building do not need to take any notice of them.
It doesn't sound completely crazy, but I doubt that implementing such
field is worth the trouble. How many packages would benefit from it? Do
you have any concrete examples?