From: Eric Garver <eric@garver.life>
To: Phil Sutter <phil@nwl.cc>, Jeremy Sowden <jeremy@azazel.net>,
Netfilter Devel <netfilter-devel@vger.kernel.org>,
Michael Biebl <biebl@debian.org>
Subject: Re: iptables: reverting 34f085b16073 ("Revert "xshared: Print protocol numbers if --numeric was given"")
Date: Wed, 3 Jul 2024 15:17:52 -0400 [thread overview]
Message-ID: <ZoWj4FBGF4E0Fwb3@egarver-mac> (raw)
In-Reply-To: <ZoWB2Qo_vi-YIRqc@orbyte.nwl.cc>
On Wed, Jul 03, 2024 at 06:52:41PM +0200, Phil Sutter wrote:
> Hi Jeremy,
>
> On Wed, Jul 03, 2024 at 05:02:04PM +0100, Jeremy Sowden wrote:
> > At the beginning of the year you committed 34f085b16073 ("Revert
> > "xshared: Print protocol numbers if --numeric was given""), which
> > reverts da8ecc62dd76 ("xshared: Print protocol numbers if --numeric was
> > given").
>
> I did this in response to nfbz#1729[1] which argued the names are more
> descriptive. This is obviously true and since commit b6196c7504d4d there
> is no real downside to printing the name if available anymore (--numeric
> still prevents calls to getprotobynumber()).
>
> Personally I don't mind that much about changing --list output as it is
> not well suited for parsing anyway. I assume most scripts use
> --list-rules or iptables-save output which wasn't affected by
> da8ecc62dd76. Of course I am aware of those that have to parse --list
> output for one or the other reason and their suffering. The only bright
> side here is that whoever had to adjust to da8ecc62dd76 will know how to
> adjust to 34f085b16073, too. Plus it's not a moving target as there are
> merely twelve names which remain in '-n -L' output.
>
> > In response to a Debian bug-report:
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067733
> >
> > I applied the change to the iptables package and uploaded it. However,
> > this caused test failures in the Debian CI pipeline for firewalld
> > because its test-suite has been updated to expect the new numeric
> > protocol output. Michael Biebl, the firewalld Debian maintainer, (cc'ed
> > so he can correct me if I misquote him) raised a point which I think has
> > some merit. It is now eighteen months since 1.8.9 was released. One
> > imagines that the majority of iptables users, who presumably are not
> > building iptables directly from git, must, therefore, have adjusted to
> > the new output. Is it, then, worth it to revert this change and force
> > them to undo that work after what may have been a couple of years by the
> > time 1.8.11 comes out?
> >
> > What do you think?
>
> I think it's a mess and there's no clean way out. The current code is at
> least consistent between '-S' and '-L' output (iptables-save should not
> be "less numeric" than '-n -L'). If it helps, I can work with Eric to
> solve the problem for firewalld so Michael will have something to
> backport to fix it.
The firewalld testuite failures have been fixed [1]. The revert exposed
a bug in the testsuite normalization. It's not actually caused by the
revert of iptables da8ecc62dd76.
Michael could backport this to Sid.
[1]: https://github.com/firewalld/firewalld/pull/1360
> All in all I have not seen many complaints about this change, I expect
> few people scraping iptables output and only a fraction doing --list.
> In addition to that, I plan on soon having a 1.8.11 release (we're far
> ahead already to make backports a pain).
>
> What do you think?
I'm indifferent. As you say, there is no clean way out.
next prev parent reply other threads:[~2024-07-03 19:18 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-03 16:02 iptables: reverting 34f085b16073 ("Revert "xshared: Print protocol numbers if --numeric was given"") Jeremy Sowden
2024-07-03 16:52 ` Phil Sutter
2024-07-03 19:17 ` Eric Garver [this message]
2024-07-04 20:19 ` Jeremy Sowden
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZoWj4FBGF4E0Fwb3@egarver-mac \
--to=eric@garver.life \
--cc=biebl@debian.org \
--cc=jeremy@azazel.net \
--cc=netfilter-devel@vger.kernel.org \
--cc=phil@nwl.cc \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.