On 30/10/06 at 17:36 +0200, Magnus Holmgren wrote: > If an architecture-independent binary package fails to build because the build > target runs a test that needs network access, should that be considered > release critical, if the package requires network access to function in any > useful manner? Since the package is Architecture: all, no autobuilding is > needed on Debian's part, and building from source with dpkg-buildpackage > works in all normal situations. Hi, I've worked/am working on archive rebuilds of etch currently, and I'm concerned about this issue too, since my build environment doesn't allow me to access the Internet. > The concrete example I'm referring to is a simple Perl package > (libmail-dkim-perl, http://bugs.debian.org/395860). I'm only rebuilding etch, so I didn't try this package. However, here is a list of packages that accessed the network in some way other than DNS during their build. Packages which accessed the network AND failed to build (might be unrelated): (6 packages) libimage-info-perl 1.22-1 libmath-randomorg-perl 0.03-2 libpoe-component-client-http-perl 0.65-1 libwww-myspace-perl 0.48-2 python-vobject 0.0.svn155-2 rhino 1.6R2-1 Packages which accessed the network but built successfully: (62 pkgs) bcfg2 choose-mirror control-center db4.2 debian-edu debian-med exim4 fast-user-switch-applet finance-yahooquote gnome-doc-utils gnome-power-manager gnunet-gtk gtkmm2.0 imapcopy jmock kdetv kvpnc libcommons-codec-java libcommons-collections3-java libcommons-collections-java libcommons-dbcp-java libdtdparser-java libmail-cclient-perl libnet-z3950-perl libpoe-component-irc-perl libspork-perl libweather-com-perl libxml-stream-perl lucene mailagent omnievents passepartout perl php-benchmark php-cache php-cache-lite php-http-request php-image-canvas php-image-graph php-log php-net-checkip php-net-dime php-net-ftp php-net-ldap php-net-sieve php-net-smartirc php-net-url php-pager php-services-weather php-simpletest php-soap phpunit2 php-xml-serializer php-xml-util postgis pugs python-markdown sensors-applet sitemap stlport4.6 urlgrabber vdk2 My point of view would be that accessing the network during the build is RC if: - a network failure causes the build to fail OR - a network failure causes the generated package to be different from the one generated when the network is available (files missing, for example). (some packages amongst the 62 pkgs above might be in this case) Some packages (e.g choose-mirror) fetch a newer version of a file during build if it's possible to fetch that file. I don't think this is RC, since the file is not missing from the package if the network is not available. That was my humble opinion, and I'm not a DD. > Normally, Debian, as a distribution, provides > a coherent platform in the form of a set of packages that have been tested > together, so that if the build dependencies are met, then the package builds, > and if the normal dependencies are met, then it runs. Running tests on many > computers with identical environments is then a bit redundant. Such "redundant" tests have already been proven useful numerous times. Changes in other packages can influence the behaviour of a package, and the fact that a package builds if its build dependencies are satisfied can only be considered true at the time of its upload, if the maintainer has made the proper tests (build in a clean chroot/pbuilder). Regards, -- | Lucas Nussbaum | lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |
Attachment:
signature.asc
Description: Digital signature