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 <k...@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 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
