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.

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.

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?

In case you want a stop-gap measure, for now, I suggest temporarily
moving back the generator to /lib/systemd in unstable. Doing so unbreaks
the upgrade from bookworm and makes this bug non-rc, but is not a
long-term solution.

I'm happy to review a patch. Let me know if you cannot handle this and
I'll look in to preparing a NMU. If you have questions, don't hesitate
to ask.

Helmut

DEP1: https://subdivi.de/~helmut/dep17.html

Reply via email to