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

Re: autopkgtest/sbuild environment variables: LC_ALL, HOME, XDG_RUNTIME_DIR etc



On Thu, Apr 28, 2022 at 02:32:49PM +0100, Simon McVittie wrote:
> > That's interesting; I don't find any code that sets HOME in
> > autopkgtest.
> 
> The purpose of autopkgtest is to run the tests in a realistic environment
> that resembles a real Debian desktop or server, but it doesn't know much
> about how the testbed system is set up, so it relies on the virtualization
> backend or the testbed itself to set HOME appropriately. Ideally, it
> should be logging into a fully-working Debian system (perhaps under qemu
> or lxc, or even on real hardware via ssh) and running tests there.
> 
> As I said on #986665, this seems like either a bug in
> autopkgtest-virt-schroot, or misconfiguration in how you and Laurent
> are configuring it (the schroot profile that you're telling it to use).

I've thought a little bit more about this, and I realise that the
devil is in the detail, in particular the phrase "a realistic
environment that resembles a real Debian desktop or server".  A
realistic environment is likely to have lots of random packages and
services available.  It would make some sense, therefore, to be more
explicit about what is expected in this environment by default.
Here's a very small list to begin with:

1. All essential packages are installed.
2. HOME points to a readable and writeable directory.  [What is in
this directory?  Should it be cleaned before every use?]
3. XDG_RUNTIME_DIR points to ... / maybe this should be:
libpam-systemd is installed?
4. Locale LC_ALL ... should be set up in a meaningful way.
5. ... more points? ...

This will help developers to set up sensible environments.  I now know
I have been writing autopkgtest scripts that don't assume this and
therefore don't properly replicate a typical desktop environment.  But
without these assumptions made explicit, it will be hard to guess what
can be assumed and what can't be.

Best wishes,

   Julian


Reply to: