[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: ipset

On Thu, Jan 19, 2012 at 2:29 AM, Dmitry Smirnov <onlyjob@member.fsf.org> wrote:
>> Yes, I'm using xtables-addons until now and I learn to package from your
>> work :) But found this commit:
> Thank you for kind words. :)  A real pleasure.

:) For the whole day, I try to build ipset-source, ipset-dkms which
based on xtables-addons until I can remember that
ipset kernel modules already merge into the mainline kernel and no
needs to build any ipset modules or even the iptables extensions.

Despite, thank you very much that you provides the good examples for
*-source and *-dkms sources build, it's worth enough to learn.

>> "build: deactivate build of ipset-genl by default"
>> == >8 ==
>> Changes:
>> +- Deactivate build of ipset-genl by default.
>> +  I think the original ipset package can now take over, given there are
>> +  a handful of kernels (2.6.39 onwards) that do not need patching.
>> == 8< ==
> Interesting.
> We haven't started packaging this version yet.
> Originally I got involved to xtables-addons due to lack of working ipset6.

Is "ipset6" means ipset for IPv6 ? or ipset (6.x) ?
I'm interested in the IPv6 with ipset but not tested yet. The IPv6 is
not widely used in Thailand yet.

>> Therefore, I intend to package "ipset" again with libipset{2-dev} included.
> I'm not sure what would be the best in this case.
> It is convenient to have iptables modules in one package.

Sure, I understand your point and if xtables-addons provides libipset
is very good and no needs to separates the
maintaining jobs.
But I think, we should ask the upstream of xtables-addons about the
ipset in the next future releases.

> I reckon you're aware that your package conflicts with xtables-addons-common?

At this time, my ipset binary still conflicts as the
xtables-addons-common also provides the binary in the same path.

IMO, if the next release (1.41) of xtables-addons will not build
ipset, so, ipset package should set the Conflicts to only for
xtables-addons-common (<= 1.40) then no conflicts any more.

Or setup the alternatives which users could select by him/her self.

Or ipset source package should build only libipset{2,-dev} and leave
the ipset utility in xtables-addons as before.

But I respect your and xtables-addons maintainer team's decision.
Any suggestions ?

Best regards,
Neutron Soutmun

Reply to: