Le Mon, Feb 09, 2009 at 09:30:48AM +0100, Fabian Greffrath a écrit : > Dear -devel, > > I'd like to suggest the introduction of two new control fields to the > source stanza of debian/control, namely Build-Recommends and > Build-Suggests.
Dear Fabian, this is a very intersting proposal that would address perfectly the issues I had with running regression tests with Perl modules. Let's imagine possible consequences (in the case of Perl modules) of unavailability of a package in one of the three Build- fields: - Binary packages would be impossible to prepare if Build-Depends are not completely satisfied. - Regression tests would miss some information if Build-Recommends are missing, but building would not fail and the binary package would be identical, i.e., the only diffrerence would be the logs. Advantage: a package does not become instantaneously unbuildable if one of its Build-Recommends is unavailable for whatever reason. - Regression tests would get additional information if Build-Suggests are present. Typically, Build-Suggests could be used with contrib or non-free packages. Here is a real life example: the bioperl-run package provides wrappers for many programs and regression tests for all the wrappers; most programs are packaged, and would go to to Build-Recommends, but some (clustalw, phylip) are non-free, and would go in Build-Suggests. Bioperl-run's regression tests do not fail if the wrapped programs are not found. This said, there are insightful comments in this thread that underline what should not be done with Build-Recommends in the context of packages that need compilation, so the need for the two new fields, althoug appalling, is probably not pressing. I guess that if you manage to convince the dpkg and sbuild maintainers to implement them, you will have more chances to get the fields accepted ;) Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org