Assumptions about $ADTTMP

[Christian Kastner]

Hi Martin,

On 2014-09-24 18:15, Martin Pitt wrote:
> Hey Christian,
> 
> Christian Kastner [2014-09-24 10:13 +0200]:
>> That leads me to wonder: what can test developers safely assume about
>> $ADTTMP?
> 
> 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.

Thank you for these suggestions. I believe the first one is the least
intrusive, and accomplishes exactly what I want.

> 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.

That sounds reasonable. Thank you for clarifying!

Regards,
Christian