From mboxrd@z Thu Jan  1 00:00:00 1970
From: Matthias Fischer <matthias.fischer@ipfire.org>
To: development@lists.ipfire.org
Subject:
 Re: Duplicate files created by 'iptables 1.6.0' and 'ebtables 2.0.10-4'
Date: Fri, 01 Apr 2016 17:02:51 +0200
Message-ID: <56FE8D9B.7060009@ipfire.org>
In-Reply-To: <56FE1376.9000804@ipfire.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8529927247747390241=="
List-Id: <development.lists.ipfire.org>

--===============8529927247747390241==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On 01.04.2016 08:21, Matthias Fischer wrote:
>> > I was actually asking if ebtables is merged into the iptables package.
> Ups. Sorry, "academical misunderstood"...
>=20
>> > Maybe we should stay on the last release?!
> For now, I'd say 'Yes'! I'll take a closer look at it!

Looking through the 'iptables'-changelog and comparing the various
source codes seems to show that a "compat-part" of ebtables' was merged.
Since then it is developed as a (new) part of 'iptables':

'iptables' changelog:
...
ebtables-compat: [various entries]
...
Merge branch 'ebtables-compat'
...

This would be in context with the fact that only a few equivalent
source-files from the 'ebtables'-extensions-directory
(extensions/ebt_*.c) can be found in the corresponding
'iptables'-extensions-directory (extensions/libebt_*.c).

As I see it from here, the 'ebtables'-package *could* be obsolete, or
maybe *not*, depending on what purposes we need it for, or what
functions we want. Hard to tell for me, sorry.

@Jonatan:
Perhaps you could test 'iptables 1.6.0' with your actual branch - and
without 'ebtables', to see if 'ebtables' are really needed, especially
by 'libvrt'? Just an idea...

Best,
Matthias

>>>> >> > Can you disable it?
>>> >> Thats why I'm asking here. I found no option yet to disable building t=
he
>>> >> 'libebt*-files in 'iptables 1.6.0'. For now I just commented the
>>> >> duplicate files in the new 'iptables'-rootfile. If thats all I have to
>>> >> do, then everything is fine. If not, we'll have to look for another
>>> >> solution. I don't know - and can't judge yet - if commenting these fil=
es
>>> >> could have any unwanted effects to any 'iptables'-functions. As long as
>>> >> we stick to the '1.4.21'-version, nothing will happen.
>> >=20
>> > I think if you try to load the wrong files that should certainly break t=
hings as
>> > there will be an ABI mismatch.
>> >=20
>>> >>=20
>>> >> By the way: at this moment, an additional test build, containing the
>>> >> five updates from my previous post, was finished. Without any errors,
>>> >> but again with the duplicates from 'iptables 1.6.0' and from 'ebtables=
'.
>>> >> Do you want me to send the diffs? I could push them to GIT so you could
>>> >> take a look.
>> >=20
>> > No need for me.
>> >=20
>>> >>=20
>>> >> Best, Matthias
>>> >>=20
>>>> >> >=20
>>>> >> >=20
>>>> >> > -Michael
>>> >>=20
>>>> >> >=20
>>>> >> > On Tue, 2016-03-29 at 20:37 +0200, Matthias Fischer wrote:
>>>>> >> > >=20
>>>>> >> > > Hi,
>>>>> >> > >=20
>>>>> >> > > As I wrote before I'm testing with 'iptables 1.6.0'.
>>>>> >> > >=20
>>>>> >> > > While looking which files I would need to backup so I could run =
some
>>>>> >> > > tests on my production machine I found that 'iptables 1.6.0' and=
 current
>>>>> >> > > 'ebtables 2.0.10-4' are building duplicate files.
>>>>> >> > >=20
>>>>> >> > > 'ebtables' puts them in '/usr/lib', 'iptables 1.6.0' in '/lib/xt=
ables':
>>>>> >> > >=20
>>>>> >> > > libebt_802_3.so
>>>>> >> > > libebt_ip.so
>>>>> >> > > libebt_log.so
>>>>> >> > > libebt_mark_m.so
>>>>> >> > >


--===============8529927247747390241==--