[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Test suites after build and Build-Depends.



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


Reply to: