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

Reply via email to