Bug#1078598: piuparts.debian.org: oldstable22testing, oldstable222sid should not fail on /usr moves

Package: piuparts.debian.org
Severity: normal
X-Debbugs-Cc: [email protected]

piuparts.debian.org currently reports test failures for many packages
in the "oldstable22testing" upgrade path (oldstable → stable → testing)
and the "oldstable222sid" upgrade path (oldstable → stable → testing → sid)
as a result of files having been moved from /foo to /usr/foo.
For example, libaccountsservice-doc:all reports these:

0m48.6s ERROR: FAIL: File(s) moved between /{bin|sbin|lib*} and /usr/{bin|sbin|lib*}:   /lib/x86_64-linux-gnu/libblkid.so.1.1.0 ['libblkid1:amd64'] => /usr/lib/x86_64-linux-gnu/libblkid.so.1.1.0 ['libblkid1:amd64']
  /lib/x86_64-linux-gnu/libblkid.so.1 ['libblkid1:amd64'] => /usr/lib/x86_64-linux-gnu/libblkid.so.1 ['libblkid1:amd64']
  /lib/x86_64-linux-gnu/libfdisk.so.1.1.0 ['libfdisk1:amd64'] => /usr/lib/x86_64-linux-gnu/libfdisk.so.1.1.0 ['libfdisk1:amd64']
  /lib/x86_64-linux-gnu/libfdisk.so.1 ['libfdisk1:amd64'] => /usr/lib/x86_64-linux-gnu/libfdisk.so.1 ['libfdisk1:amd64']
  /lib/x86_64-linux-gnu/libgcrypt.so.20 ['libgcrypt20:amd64'] => /usr/lib/x86_64-linux-gnu/libgcrypt.so.20 ['libgcrypt20:amd64']
  /lib/x86_64-linux-gnu/libmount.so.1.1.0 ['libmount1:amd64'] => /usr/lib/x86_64-linux-gnu/libmount.so.1.1.0 ['libmount1:amd64']
  /lib/x86_64-linux-gnu/libmount.so.1 ['libmount1:amd64'] => /usr/lib/x86_64-linux-gnu/libmount.so.1 ['libmount1:amd64']
  /lib/x86_64-linux-gnu/libsmartcols.so.1.1.0 ['libsmartcols1:amd64'] => /usr/lib/x86_64-linux-gnu/libsmartcols.so.1.1.0 ['libsmartcols1:amd64']
  /lib/x86_64-linux-gnu/libsmartcols.so.1 ['libsmartcols1:amd64'] => /usr/lib/x86_64-linux-gnu/libsmartcols.so.1 ['libsmartcols1:amd64']
  /lib/x86_64-linux-gnu/libsystemd.so.0 ['libsystemd0:amd64'] => /usr/lib/x86_64-linux-gnu/libsystemd.so.0 ['libsystemd0:amd64']
  /lib/x86_64-linux-gnu/libudev.so.1 ['libudev1:amd64'] => /usr/lib/x86_64-linux-gnu/libudev.so.1 ['libudev1:amd64']
  /lib/x86_64-linux-gnu/libuuid.so.1.3.0 ['libuuid1:amd64'] => /usr/lib/x86_64-linux-gnu/libuuid.so.1.3.0 ['libuuid1:amd64']
  /lib/x86_64-linux-gnu/libuuid.so.1 ['libuuid1:amd64'] => /usr/lib/x86_64-linux-gnu/libuuid.so.1 ['libuuid1:amd64']
  /lib/udev/hwclock-set ['util-linux'] => /usr/lib/udev/hwclock-set ['util-linux-extra']
  /lib/udev/rules.d/85-hwclock.rules ['util-linux'] => /usr/lib/udev/rules.d/85-hwclock.rules ['util-linux-extra']

Clearly none of those are actually acccountsservice's fault, and my
understanding is that none are even considered to be a problem.

The Debian Technical Committee issued advice that files should not be moved
from /foo to /usr/foo during the Debian 12 release cycle (#994388) and
the early part of the Debian 13 release cycle (#1035831), but this
moratorium was lifted in late 2023 (#1053901) and, instead, there has been
an ongoing effort to relocate files from /foo to /usr/foo. I believe the
goal is that the only package owning paths in /{bin,sbin,lib*} in trixie
will be base-files.

As a result, I think piuparts should stop reporting these moves as errors
in upgrade paths whose end state is Debian 13 'trixie' or later.
It would still be appropriate to report /foo → /usr/foo moves as errors if
the end state is Debian 12 'bookworm' or older, as per #994388.

If I'm reading the configuration in
https://salsa.debian.org/debian/piuparts/-/blob/develop/instances/piuparts.conf-template.pejacevic
correctly, it might be appropriate to keep "--warn-on-usr-move fail" in
"flags-end-bookworm", but remove it from "flags-start-bullseye"?
That way, the moratorium on /foo → /usr/foo moves would still be enforced
for bullseye → bookworm, but not for bullseye → bookworm → trixie, which I
think is what we want.

Or, it might be better to remove "--warn-on-usr-move fail"
from both "flags-end-bookworm" and "flags-start-bullseye", and instead
add it to each of the finite number of test scenarios where the end state
is strictly older than trixie (including bookworm, bookworm-pu, etc.).

Thanks,
    smcv