Hi Helmut,
thank you very much for the detailed bugreport and your sepcific hints!
Am 12.01.24 um 11:00 schrieb Helmut Grohne:
Package: netplan-generator
Version: 0.107.1-1
Severity: serious
Justification: file loss in package upgrade
User: helm...@debian.org
Usertags: dep17p1
Control: affects -1 + netplan.io
Hi Lukas,
netplan was on my radar for /usr-merge for a while, but unfortunately I
didn't get down to it before bad things happened.
I think this is your first upload since we changed systemd.pc to point
to /usr. Earlier, netplan-generator would install
/lib/systemd/system-generators/netplan and since this upload it installs
to the same location below /usr. This wouldn't be a problem if that file
weren't installed in netplan.io in bookworm. Now upgrading from bookworm
to unstable would both move this file from / to /usr and from netplan.io
to netplan-generator. Normally, the Replaces that you declare are
sufficient, but the aliasing added by /usr-merge changes this and makes
the file subject to loss in an upgrade. For more information refer to
DEP17 P1.
Indeed, systemd's pkgconfig variables changed, which made Netplan's generator
to be installed into /usr/lib/
You have two possible mitigations for this. The simple mitigation (DEP17
M7) is upgrading those Breaks+Replaces for netplan.io to Conflicts. This
still can cause file loss if netplan.io is being removed in an upgrade
where netplan-generator is being installed and the upgrade is being
performed with dpkg. I'd consider that relatively unlikely.
If you want to handle this case correctly, the recommended way is using
"protective diversions" (DEP17 M8). You keep Breaks+Replaces as is and
extend maintainer scripts.
netplan-generator.preinst:
dpkg-divert --no-rename --divert
/lib/systemd/system-generators/netplan.usr-is-merged --add
/lib/systemd/system-generators/netplan
netplan-generator.postinst:
dpkg-divert --no-rename --divert
/lib/systemd/system-generators/netplan.usr-is-merged --remove
/lib/systemd/system-generators/netplan
This diversion redirects the deletion of the file being replaced to a
location that does not exist and hence prevents the loss.
Let's try to handle it the correct way!
I took your input and prepared a Salsa MR around it.
I'd like to ask for your review and comments on this [1].
Beyond this, there also is an issue with /usr/lib/netplan. It is an
empty directory and since netplan.io formerly installed files to
/lib/netplan, removing netplan.io can make dpkg think that /lib/netplan
can be deleted. When it does so, it actually deletes /usr/lib/netplan
(DEP17 P6). Your options are:
* Do not install /usr/lib/netplan and make the generator work in the
absence of that directory.
* Ship a placeholder file inside.
* Have a postinst script that recreates it after loss. For this to
work, you have to install a trigger interest in /lib/netplan to make
dpkg rerun your postinst after the loss.
On top of this, none of the moves nor mitigations are applicable to
bookworm. If you plan to support backports for bookworm, you need to
ensure that such backports do not move files to /usr. It also means that
your possible M8 mitigation has to add protective diversions on every
upgrade without a version check as it could be upgrading from
bookworm-backports. Can you handle these issues?
This will also be addressed in the above mentioned MR.
For now I'll go with the placeholder file, but longer term I want to avoid
installing that directory all together.
The latter would have some side-effects on Ubuntu's NetworkManager package (integrated with Netplan),
due to some systemd hardening flags in use: "ProtectSystem=true" &
"ReadWritePaths=/usr/lib/netplan"
Thanks!
Lukas
[1] https://salsa.debian.org/debian/netplan.io/-/merge_requests/11
