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

Assumptions about $ADTTMP

Hey Christian,

Christian Kastner [2014-09-24 10:13 +0200]:
> That leads me to wonder: what can test developers safely assume about

At the moment this is just an mktemp -d in whichever testbed you use.
So at the moment the only assumptions that you can make are what
doc/README.package-tests.rst describes:

  During execution of the test, the environment variable ``$ADTTMP``
  will point to a directory for the execution of this particular test,
  which starts empty and will be deleted afterwards (so there is no
  need for the test to clean up files left there).

> Would it be possible, and make sense, to be more explicit about
> its nature? filesystem type, mount options, a guarantee on the minimum
> space available, etc.

This all depends on the type (schroot, LXC, QEMU, null, ssh, etc.) and
particular configuration of the testbed, so in general you can't make
any further guarantees with current autopkgtest. E. g. in many
environmens adt-run doesn't have root privileges, and even those don't
help with guaranteeing a minimum space available.

For your case I see two options: You could declare "needs-root" (your
test needs that anyway, I figure) and mount a tmpfs somewhere with the
desired options. Or you put your binaries in /usr/bin/ which cannot
sensibly be mounted with nosuid anywhere; in this case it might be
prudent to declare "breaks-testbed" if you can't guarantee a proper
cleanup, so that people don't try and run this with the null runner.

It might be possible to provide stronger guarantees of $ADTTMP for
testbeds which provide root; but they often conflict: e. g. it would
be simple to always use a tmpfs in these cases, but then the storage
space would be quite limited. Or the next test doesn't get along with
a RAM file system as it does not exhibit the typical behaviour of a
disk backed one.

I'm hesitant to add things like the above as they are almost
impossible to enforce and make sense in the general case. An
individual test knows a lot better what it needs, and can then set
up/mount loop images/tmpfses as it desires, and skip itself if it
doesn't find enough space for its purposes.



Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Reply to: