On Fri, 28 Jul 2023 at 11:53:29 +0200, Carsten Schoenert wrote:
> To quote from the BTS:
> ---%<---
> > In 1.2 upstream added a test suite. We should run it during build
> > (cd common && $(MAKE) test) but it needs to be able to write to the home
> > directory, which is disabled on Debian auto-builders. Need to find
> > a solution to that.
> --->%---
> To me it's clear what the problem is. The test requires a $HOME folder, but
> the build environment doesn't provide something like this.

If backintime uses $HOME, and doesn't rely on $HOME being the same as
$(getent passwd $(id -u)|cut -d: -f6), then it might actually be possible
to run its test suite with a dependency on a suitably new debhelper.

In debhelper compatibility level 13, dh_auto_test sets $HOME to a temporary
directory (#942111) which might well be enough to run the test suite
non-destructively. If that's sufficient, I'm sure the maintainer of the
backintime package would appreciate a tested patch sent to #940319.
The way to test this would be to build backintime in sbuild, with a uid
whose "official" home directory in /etc/passwd doesn't exist in the chroot.

The other angle this could be approached from is as an upstream developer:
as an upstream, would you really want running the backintime test suite
to make potentially destructive changes to your real home directory? As
an upstream developer of other packages, I wouldn't want that: if I have
made an implementation mistake, I want to be able to find out about that
by running the test suite, knowing that the test suite won't damage my
real home directory.

Making the test suite write to a mock home directory instead of to the
real home directory, and changing or unsetting environment variables that
point to the real home directory (again, see #942111) during automated
testing, would make the test suite safer and more predictable.


Reply via email to