Le 20/09/2022 à 11:41, Luca Boccassi a écrit :
Most of the issues would crop up when actually attempting to move
things,
Interrupting a running upgrade is always problematic. Lots of
packages are then in broken state (half installed). Apt has
difficulties to recover from such a situation. Sometimes, it
needs additional packages requiring a working network
(but network-manager can be broken at this point...)
so a dry-run would be a lot of work and provide little benefits
I think.
The goal of the dry-run would be to be run *before* the
upgrade start (with the debconf framework) so that the
admin can fix any conflict situation described by your
matrix when they still have a working system.
The other "solution" is to do an upgrade in two-stage
1) install usrmerge
2) do the real upgrade
So, a kind of do-release-upgrade (as Ubuntu has)
To be thorough you'd have to replicate the filesystem
somewhere else and try it there first, but that requires a huge amount
of disk space and a lot of time too,
I do not understand this argument. While would we need
to replicate the FS? I'm just thinking to explore the
FS (/lib, ...) and check there is no conflicts as listed
in your matrix.
so it doesn't seem worth it, given
in 5+ years on multiple distros this is the first case we've seen.
I think what we should add is debsums -c before/after, and fail if
something is not right, so that there's an immediate and clear error
plus recovery step presented. I've sent a patch to Marco for this.
debsums is very long to be run on a big system or on a system
with old (magnetic) disks. Running it twice would lead
to a very long installation time of usrmerge.
But I'm glad we figured out what went wrong, as it was a very puzzling
case. With my systemd maintainer hat on: you shouldn't move these files
away to /etc. Units shipped in /usr|/lib are fixed vendor-provided
files, and must not be modified. Local modifications should instead
happen on /etc or /run. I strongly advise to fix that on your system.
(of course we still need usrmerger to support the generic case, that
goes without saying)
You do not understand my goal. I never modified files in
/etc/conffiles-out-etc/ These are the unmodified file shipped
in /lib/systemd/system.
My goal in putting them here is that they are tracked by
etckeeper, so that I can easily see their modifications during
an upgrade. It happens a few times that this help me to
quickly revert a change I do not want for my system for the
default settings. In this cases, the fix goes to
/etc/systemd/system/ as it should. Being able to look at
the history of these default configuration files is really a
good point for me (hence this change done on several of
my machines)
Regards,
Vincent
