I too vote for (3). I think (2) would be the next least-bad option but given the fundamental-ness of util-linux I think it's better to be safe.
Cheers, mwh On Sat, 19 Feb 2022 at 02:43, Paride Legovini <par...@ubuntu.com> wrote: > Bryce Harrington wrote on 18/02/2022: > > On Thu, Feb 17, 2022 at 01:00:07PM +1300, Matthew Ruffell wrote: > >> 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. > >> > >> e.g. lsblk -P now outputs LOG_SEC instead of LOG-SEC. > >> > >> 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. > > > > I think your hunch for #3 does sound like the safer approach to me as > > well. Unless there's a huge number of users asking for the new feature, > > those who do need it can either wait until it's generally available, or > > use a workaround with some awk filters or whatnot. > > I'm also +1 on option (3). The issue I can see with (3) is with > downstream software parsing `lsblk --version` to know how to deal with > the output of -P. However (2) is not a solution for this (we'd still > diverge from the upstream behavior for that version) and option (1) has > the issues you mentioned. > > Paride > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel >
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel