Comment 28 for bug 1922898

Defining the netplan.io -> libnetplan0 dependency as "libnetplan0 (= ${binary:Version})" makes it work for this specific "unattended-upgrade case", but unfortunately the regression is more generic than that... There are some other consumers of libnetplan0, such as the NetworkManager snap on Ubuntu Core 20, which will fail in the same way if the new libnetplan0 v0.102 is in place.

I've used git-bisect to find the relevant commit and even found TWO of them:
1) https://github.com/canonical/netplan/commit/6c8ed65df7c7f31280d5d27b67195a1e9a746e7a
2) https://github.com/canonical/netplan/pull/181/commits/4275ade922b63ddacc2db2aba9b413ba71836a04

Commit (2) is part of PR#181, itself part of the huge PR#193: https://github.com/canonical/netplan/pull/193

If both of them are reverted, the old (v0.101) "generate" binary can be executed nicely, using the newer (v0.102 + two reverts) library. Unfortunately, we cannot just revert those commits, as they provide some of the core functionality of netplan v0.102...

Both commits have in common that they add new data to the "NetplanNetDefinition struct", making it grow in size. So we're probably crossing some kind of memory boundary here, breaking the ABI.

I need to dig deeper, in order to find a proper way to solve this.