On Thu, Jul 21, 2022 at 08:27:15AM +0200, Marc Haber wrote: > The tests expect the test environment to be fresh.
When I wrote the initial autopkgtests, my thought was that this was the entire design idea of the system. Each stanza in the debian/tests/control file results in the instantiation of a new chroot or container before its named collection of tests is run. The tests in each stanza, of course, use the same environment. That was the reasoning behind saving and restoring /etc/passwd and friends in the Perl BEGIN and END blocks of each test script. Not perfect, but it speeds up the tests. > They relay too much on uids being the same and do not preseed adduser > to provide reproducible uids. I can understand that this is a problem. If new Debian system users or groups are added to the base files, or if default ID ranges change, we have an issue when specific ID numbers are relied upon. This was why my tests mainly picked usernames and not ID numbers. If Debian ever puts the user "foo" in the base system, we'll need to do a find and replace to change "foo" to something else. ID numbers will be harder to change, so they should be avoided or selected dynamically. > Reproducer: > - create test chroot > - adduser --system foo > - deluser foo > - verify that foo is actually gone > - run autopkgtests > - see not just one test failing. This seems like it shouldn't fail. However, there are probably side effects here that the tests handle that aren't handled by doing this interactively first. In principle, I think that picking a set of canonical usernames to work with in tests should be fine. Picking fixed ID numbers is probably not fine. -- Jason Franklin
