Re: [PATCH] build: put xtables.conf in EXTRA_DIST

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Tue, Jan 17, 2023 at 05:03:18PM +0100, Phil Sutter wrote:
> On Tue, Jan 17, 2023 at 04:56:35PM +0100, Pablo Neira Ayuso wrote:
> > On Tue, Jan 17, 2023 at 04:50:27PM +0100, Phil Sutter wrote:
> > > On Mon, Jan 16, 2023 at 06:18:34PM +0100, Jan Engelhardt wrote:
> > > > 
> > > > On Monday 2023-01-16 12:57, Pablo Neira Ayuso wrote:
> > > > >On Fri, Jan 13, 2023 at 12:47:30PM +0100, Phil Sutter wrote:
> > > > >
> > > > >IIRC ebtables is using a custom ethertype file, because definitions
> > > > >are different there.
> > > > >
> > > > >But is this installed file used in any way these days?
> > > > 
> > > > Probably not; the version I have has this to say:
> > > > 
> > > > # This list could be found on:
> > > > #         http://www.iana.org/assignments/ethernet-numbers
> > > > #         http://www.iana.org/assignments/ieee-802-numbers
> > > > 
> > > > With such official-ness, ebtables's ethertypes has a rather low priority.
> > > 
> > > This header statement exists even in legacy ebtables repo' version. I
> > > fear the opposite is the case and everyone's rather copying from ebtables
> > > or iptables just to provide /etc/ethertypes without depending on the
> > > tools.
> > > 
> > > My local Gentoo install at least has /etc/ethertypes exactly as in
> > > ebtables repo and the package source states "File extracted from the
> > > iptables tarball".
> > > 
> > > Maybe we're the original source?
> > 
> > In ebtables, there _PATH_ETHERTYPES which is indirectly used by
> > getethertypebyname() by a few extensions.
> > 
> > In iptables, this code exists too, using a different definition:
> > 
> > include/xtables.h:#define XT_PATH_ETHERTYPES     "/etc/ethertypes"
> > 
> > extensions/libebt_arp.c:                        ent = xtables_getethertypebyname(argv[optind - 1]);
> > extensions/libebt_vlan.c:                       ethent = xtables_getethertypebyname(optarg);
> > 
> > It seems this file is required by a few extensions and the translation
> > infrastructure.
> 
> Thanks for investigating. I guess dropping a file we depend on to exist
> *and* introduced in the first place is shooting one's own foot with
> extra steps. Also packagers are used to ignore the file (if not needed)
> already. :)

TBH, I thought this was too a left-over, it is good to revisit stuff.