Dear Stefano, Adeodato and Noah, thank you for your answers. Indeed, I wrote my previous mail after packaging half a dozen of perl modules, plus enabling tests in a python package. For compiled programs, the situation is definitely more simple. However, as Stefano noted, there may be sometimes more things to depend on. In particular, some of the packages I worked on recently provide wrappers for other programs, which can have complex dependancies as well. This is why for instance I end up pulling mysql-common when cowbuilding python-biopython (I miserably failed to arrange the test target correctly for sbuild). This "spagetthi effect" is what I thought about when I wrote "unnecessarly complex": I felt a bit afraid that in some situations where some packages are temporarly mutually incompatible, we can end up in a situation where the source package that depends on it is not rebuidable unless the tests are disabled.
In addition, I thought that the 'notest' build option that was discussed last year (or the year before?) on this list made it into the Policy, but I was wrong. Maybe I overvaluated this issue. In the context of a 'notest' option, listing the packages on which the source package build-depends only for the tests would make sense, so that their installation can be skipped as well. Probably we can postpone the discussion until there are serious attempts to push 'notest' to our build toold and the Policy. In the packages I prepared, I ended up duplicating the binary packages's Depends, Recommends and Suggests (excluding the non-free ones) into the Build-Depends field. Fortunately, we can intercalate comments, so I documented which packages are needed for building and which are needed for testing. As for the most complex packages, keeping these two lists synchronised is error-prone, I will think about a 'control.in' system as Adeodato suggested. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
