Yaroslav Halchenko writes ("Re: package testing, autopkgtest, and all that"):
> in the core -- users usually do not deal with source packages; many of
> them do not even have deb-src lines for apt. They do not care how
> things are built, but if we want them to contribute by testing their
> systems, the simplest approach is exposing test batteries as binary
> packages. Of cause, user-friendly front-end might overcome those
> difficulties even if tests are provided in source packages.
I don't understand what your usage model is. Are you expecting random
users to execute the tests ? Why would they do that ? What kind of
useful outcome is this likely to produce ?
I think that someone who doesn't have a "deb-src" line in their
sources.list, and has no knowledge of the existence of source
packages, is very unlikely to produce a useful bug report which leads
to an improvement to the software.
Making test suites highly end-user-visible is simply likely to result
in a lot of noise.
> > - Binary packages get entries in a large number of databases both
> > in our central infrastructure and on users' systems
>
> and imho it is ok -- we already have -dbg packages which are also of
> marginal importance to users, unless they need them, so they get
> installed them explicitly
A much larger proportion of the users of libfoo-dev are likely to want
to install libfoo-dbg, than the proportion of the users of coreutils
who want to run its regression tests. Furthermore, if you wanted
libfoo-dbg then a copy of the debug library in the built source tree
is no good to you because you want it to be picked up by your existing
build and runtime system for whatever you are compiling or running
that links against libfoo.
> for the goal of testing current system setup, installing the single,
> most recent battery, sounds sufficient. To complement there are
> snapshot.debian.org and backports.debian.org, so any previous or
> backported version could be made available
Our mechanisms for downloading and installing specific binary packages
from different source are not very well-developed.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/19785.33457.397049.476...@chiark.greenend.org.uk
