Should we change the behaviour of -P for lsblk in util-linux for Jammy?

[Matthew Ruffell]

Hi all,

I'm looking for a bit of advice about landing a new feature in util-linux, as
things have gotten a little complicated, and with feature freeze looming, a
second opinion would be much appreciated.

util-linux 2.37.2 in Jammy has introduced some new behaviour for lsblk and
similar tools which depend on libsmartcols. This switched the -P / --pairs
parameter from printing column names as normal, to changing the names to shell
compatible names instead.

e.g. lsblk -P now outputs LOG_SEC instead of LOG-SEC.

This actually broke core tools which rely on the output of lsblk -P, such as
curtin and MAAS, but I am sure there are more out there.

MAAS bug: https://bugs.launchpad.net/maas/+bug/1956613
MAAS fix: https://git.launchpad.net/maas/commit/?id=e2c01963430e6837198a54bc1eadf3efc9fdd9a2
Curtin fix: https://github.com/canonical/curtin/commit/ce811db127fe1ce46498b83615f8faed8c7dfeb6

MAAS changed from -P to -J, where the column names have not changed. Curtin
checks for the changed MAJ_MIN and sets it back to MAJ:MIN.

This all happened due to a user asking upstream util-linux to change the
behaviour for -P to be shell parsable:

https://github.com/util-linux/util-linux/issues/1201

Karel Zak obliged, and it was implemented in the following commit:

commit 58b510e5805d8350c31bfb81a47bcd38ea9fdd7e
From: Karel Zak <kzak at redhat.com>
Date: Thu, 3 Dec 2020 12:14:10 +0100
Subject: libsmartcols: sanitize variable names on export output
Link: https://github.com/util-linux/util-linux/commit/58b510e5805d8350c31bfb81a47bcd38ea9fdd7e

The thing is, now users must upgrade their MAAS and curtin versions to be able
to deploy Jammy, and I have been talking to some users who are very reluctant
to upgrade MAAS, and want another solution.

So, I asked Karel Zak about potentially reverting the change back to the old
behaviour, and putting shell compatible column names into a new parameter,
-y / --shell. This happened in the upstream bug:

https://github.com/util-linux/util-linux/issues/1594

Karel Zak was happy to oblige again, and we now have the following commits which
revert back to the old column names, and implements the new parameter:

338ad4a93 findmnt: commit missing flag
0f843ab64 lsblk: update --help output for -y
eba05f308 lsipc: add -y,--shell
152c17aa4 findmnt: add -y,--shell
9c7e81ff1 lslogins: add -y,--shell
25fb0638a lsblk: add -y/--shell
39679ea0c lsfd: use new libsmartcols functions
6fd0e3590 column: use new libsmartcols functions
0b3c2e80d include/carefulputc: remove unused function
3b5db50f7 libsmartcols: change "export" behavior, add "shellvar" flag

Great! So now things are back to the way they used to be, and users can now use
-y / --shell to get shell parsable output.

The thing is, this changed a significant amount of code, and it is split into
10+ patches, that don't cherry pick to 2.37.2 in Jammy, and need backports. The
commits are brand new, and will be a part of 2.38, but that could be months
away.

So, what I need advice on is the next steps. Should we:

1) Do nothing, accept 2.32.2 behaviour for -P in Jammy, which is a change from
Focal/Impish, and will abruptly change again with the release of 2.38 likely to
land in KK. MAAS and Curtin are already fixed, no issues there, users must
upgrade to latest stable MAAS and curtin on Jammy release. Older Curtin and MAAS
will break.

2) Backport the new 10+ commits into 2.27.2 in Jammy and hope we don't cause any
regressions with the significant amount of code being changed. We keep the same
behaviour that users expect from Focal/Impish, and users can now use
-y / --shell if they want. Older MAAS and Curtin continue to work.

3) Revert the single patch which caused all of this,
58b510e580 libsmartcols: sanitize variable names on export output
which is a tidier and well tested solution, and drop the patch when util-linux
is rebased to 2.38 in KK. This keeps existing behaviour in Focal/Impish, and
enables older MAAS and Curtin to keep working.

I'm leaning toward suggesting 3) at this stage, but this is mostly to keep
existing users happy on their older versions of MAAS.

Does anyone have any thoughts?

Thanks,
Matthew