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

Re: Enabling test requiring network on manual builds.



Hi Charles,

On Sat, Sep 19, 2009 at 11:37:24PM +0900, Charles Plessy wrote:
Hello, Perl team !

In a package I maintain outside pkg-perl (bioperl), I was curious to see the
results of the regression tests that are network-dependant and therefore
disabled at build time since the network is not available in (many of) the
machines hosting our build daemons.

I have done the following:

 # Test if DEB_BUILD_OPTIONS contains a ’network’ keyword.
 # If yes, network tests will be enabled.

 ifneq (,$(filter network,$(DEB_BUILD_OPTIONS)))
 NETWORK = --network
 endif

 build: build-stamp
 build-stamp:
       dh_testdir
       perl Build.PL $(NETWORK) < /dev/null # non-interactive, uses defaults
(…)

However, according to a search in the Debian package, this is specific to
Bioperl:

http://walrus.rave.org/source/search?q=network&path=Build.PL

Are there more generic mechanisms to manage network-dependant tests?

As I understand it, relying on network access is not allowed by default, as execution on buildd's must always produce same results and network resources cannot be expected to stay static.

...which might be what you are saying too, using other words. :-)

I would recommend to not care much about the _reason_ that you want to restrict to local builds, but just tag as "only for local builds" - which I guess really means "only for maintainer builds":

ifneq (,$(DEB_MAINTAINER_MODE))
  fail_my_build_if_copyright_seems_not_uptodate=yes
  automatically_update_build_dependencies=yes
  resolve_current_java_archs=yes
endif

Above is pseudo-code from the csound package. DEB_MAINTAINER_MODE is the actual variable that I use - inspired by the autotools AM_MAINTAINER_MODE. That third "flag" require network access as it uses rmadison to query the archs of default-jre-headless in Sid.

As package maintainer, I often use "DEB_MAINTAINER_MODE=1 debuild" or setup private build daemons with that flag set. My package might automagically "morph" into something new, and it is my own responsibility to double-check that the changes are sane, before releasing as official package.

In the past I used a custom hint in DEB_BUILD_OPTIONS too, but worried that that variable might (now or by future more aggressive ftpmasters) be interpreted as reserved for official flags only. Last I read that part of Debian Policy the wording was vague enough for multiple interpretations (or at least it was by me - a non-native speaker).

I have found that some build tools, including pbuilder, optionally preserves all environment variables starting with "DEB_" so my choice of DEB_MAINTAINER_MODE conveniently is somewhat supported in Debian already.

The idea was not mine - it was proposed to me some time ago by Romain Beauxis.


Hope that helps (and that it really relates to what you are asking),


Kind regards,

 - Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Attachment: signature.asc
Description: Digital signature


Reply to: