Interleaving Frank's and jldolan's comments here:
> I just assumed socat was not a very popular package.
My experience is the opposite! I understand it to be used in all kinds
of corners - particularly in user scripts that don't appear in the
archive.
> I've learned (and I generally agree with that) that it is better to
stick to entire upstream commits/patches (if possible) for the reason of
future maintainability.
This is true for development branch tips, but not for the maintenance of
stable releases. "Future maintainability" is minimal for socat in Focal,
for example: it hasn't had an update since before Focal's release in
2020, and is likely to only need the odd security update in the future.
SRU policy says this:
> ...the requirements for stable updates are not necessarily the same as
those in the development release. When preparing future releases, one of
our goals is to construct the most elegant and maintainable system
possible, and this often involves fundamental improvements to the
system's architecture, rearranging packages to avoid bundled copies of
other software so that we only have to maintain it in one place, and so
on. However, once we have completed a release, the priority is normally
to minimise risk caused by changes not explicitly required to fix
qualifying bugs, and this tends to be well-correlated with minimising
the size of those changes. As such, the same bug may need to be fixed in
different ways in stable and development releases.
Therefore, I do not expect to see a change to Makefile.am in this case
where changing the build system isn't necessary to fix the bug. If we
decide to go ahead with the SRU (see below), then I'd like the upload
replaced with a minimal one, please.
Improvements to test suites are generally fine though, as they pose
little risk to production users and we can benefit from such
improvements during SRU verification. As long as we aren't making the
tests less useful :)
> I think it's close to a philosophical question what is best to do in case
> "users of 20.04 relying on the current behaviour".
> I personally believe that since the behavior is wrong, that it needs to be
> corrected.
I agree that it's a difficult question. Like you, I generally lean
towards fixing bugs over changing behaviour: if the bug is obviously the
wrong behaviour, then I figure that it's perhaps a regression for
existing users that would be acceptable. So I would agree were this an
issue in Jammy. But Focal is four years old now. At this point I think
there are far more users relying on existing behaviour than new
deployments relying on correct behaviour. This is what gives me concern.
> Please notice that the behavior is correct in all releases newer than
focal - means if not fixing this now with an upgrade, things will break
at least after a dist-upgrade.
This is fine - users expect behaviour changes over a release upgrade far
more than they expect behaviour changes during the lifetime of a
release. Considering just this point, the former is actually preferable.
> Let me check with the Novalink team to see if this is an acceptable
workaround for them.
Thanks - I think this should at least be considered first given the
above concern. If you conclude that it's not possible then I can consult
with the SRU team to make a final decision.
One possibility for example is to set an environment variable like
LP2056485_SOCAT_BEHAVIOUR and have this socat SRU only activate if that
is set. mkvterm could either set that, or you could arrange a wrapper.
Then we wouldn't have to worry about changed behaviour for other users.
I don't know if this is overkill though - I'd want to consult with other
SRU team members before going ahead with it.
** Changed in: socat (Ubuntu Focal)
Status: In Progress => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2056485
Title:
Behaviour of socat in Ubuntu 20.04 unexpected
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/2056485/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
