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 [thread overview]
Message-ID: <56FE8D9B.7060009@ipfire.org> (raw)
In-Reply-To: <56FE1376.9000804@ipfire.org>
[-- Attachment #1: Type: text/plain, Size: 3100 bytes --]
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"...
>
>> > 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 the
>>> >> '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 files
>>> >> could have any unwanted effects to any 'iptables'-functions. As long as
>>> >> we stick to the '1.4.21'-version, nothing will happen.
>> >
>> > I think if you try to load the wrong files that should certainly break things as
>> > there will be an ABI mismatch.
>> >
>>> >>
>>> >> 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.
>> >
>> > No need for me.
>> >
>>> >>
>>> >> Best, Matthias
>>> >>
>>>> >> >
>>>> >> >
>>>> >> > -Michael
>>> >>
>>>> >> >
>>>> >> > On Tue, 2016-03-29 at 20:37 +0200, Matthias Fischer wrote:
>>>>> >> > >
>>>>> >> > > Hi,
>>>>> >> > >
>>>>> >> > > As I wrote before I'm testing with 'iptables 1.6.0'.
>>>>> >> > >
>>>>> >> > > 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.
>>>>> >> > >
>>>>> >> > > 'ebtables' puts them in '/usr/lib', 'iptables 1.6.0' in '/lib/xtables':
>>>>> >> > >
>>>>> >> > > libebt_802_3.so
>>>>> >> > > libebt_ip.so
>>>>> >> > > libebt_log.so
>>>>> >> > > libebt_mark_m.so
>>>>> >> > >
next prev parent reply other threads:[~2016-04-01 15:02 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1459464825.30749.255.camel@ipfire.org>
2016-04-01 6:21 ` Matthias Fischer
2016-04-01 15:02 ` Matthias Fischer [this message]
2016-04-01 15:06 ` Matthias Fischer
2016-04-08 19:03 ` Michael Tremer
2016-04-08 21:42 ` Matthias Fischer
2016-03-29 18:37 Matthias Fischer
2016-03-29 21:00 ` Michael Tremer
2016-03-29 22:06 ` Matthias Fischer
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=56FE8D9B.7060009@ipfire.org \
--to=matthias.fischer@ipfire.org \
--cc=development@lists.ipfire.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox