Package: autopkgtest Version: 5.30 Severity: normal X-Debbugs-Cc: par...@debian.org
As discussed briefly in <https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/251#note_414411>, autopkgtest has some level of (possibly vestigial) support for: - systems where the root filesystem is mounted read-only (as identified by `test -w /var/lib/dpkg/status`, which might itself be considered a bug as explained by the uses-dpkg-database-directly Lintian tag); also, elsewhere in autopkgtest, we're careful to assume that /sbin and even /var/cache might be read-only - systems where the Essential interface `dpkg-query` is missing (see https://bugs.launchpad.net/ubuntu/+source/autopkgtest/+bug/1469647, which has a regression test that has caused us extra work recently by intentionally removing an Essential interface during testing) It is not clear to me how snapd, "snappy images", Ubuntu Touch, Ubuntu Core and similar Canonical products fit together, which ones are end-of-life or no longer relevant for autopkgtest's purposes, and which ones are still current and still expected to have autopkgtests run on them. Please could the operators of Ubuntu's autopkgtest infrastructure clarify this? Ideally, I would like autopkgtest to be able to assume that it is running on a Debian system (or a derivative), with all Essential interfaces present; and if we have uid 0, then the root filesystem should be rw. Or, if a significant derivative like Ubuntu wants autopkgtest to be able to support deviations from that "normal" interface, then I would like those and the reasons behind them to be documented in debian/README.source, similar to what I did in https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/247 for our distro-version policies. Thanks, smcv
