Re: RFS: ipset
On Thu, Jan 19, 2012 at 05:31:01PM +0700, Neutron Soutmun wrote:
> I must apologize you, Pierre but I have to CC you because we need your
> suggestions.
>
[...]
> >> 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.
> >
> > This may work if we agree not to build ipset in the next xtables-addons
> > release and sponsor your package at the same time.
> > Please bring Pierre (the main xtables-addons maintainer) to the discussion and
> > CC to me as well.
>
> As mention above, I already CC Pierre.
>
> I'm not sure the intentions of the xtables-addons upstream that not to
> build the ipset-genl
> as default as in the version 1.41 but IMO, it's unnecessary to
> maintain ipset module in the separate place
> other than in the recent mainline kernel. Despite, It's still
> necessary for the xtables-addons to support
> the old kernels.
>
Hi,
[CC'ing Dmitry]
I have not followed all the discussion, but indeed the ipset modules
will cause a conflict now they are part of the standard Linux kernel.
The main interest of xtables-addons was that it could be built without
patching the kernel (thus avoiding reboots and some management of
upgrades), while the upstream ipset could not.
Now that the modules are upstream, I don't see any additional reason to
keep the ipset modules from xtables-addons.
Of course, that works only someone provides the ipset userland tool.
Is there any plan to fix #651790 ?
This way, xtables-addons can also remove the Conflicts with ipset, and
ipset can also Conflicts with xtables-addons (<< 1.4x)
Regards,
Pierre
> >> Or setup the alternatives which users could select by him/her self.
> >>²
> >
> > I don't like this idea because it is not an alternative but the very same
> > thing provided by two different packages. This should not be. :)
>
> Ok, forget it.
>
> >> 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 ?
> >
> > I hope you'll excuse me if I stay away from suggestions for some time.
> > This discussion needs expertise of someone more experienced than me - a
> > someone familiar with resolution of conflicts between packages.
> > We need comments from DDs.
> >
> > Personally I think this decision requires me to thoroughly review your package
> > and prepare new xtables-addons. I'm overwhelmed with work for next several
> > weeks so I hardly will be able to do so soon.
> >
> > Besides, I think you need to demonstrate the benefits of having separate
> > package for ipset. I'm not sure how/why this is better (if it is) or if it's
> > worth troubles to do for the marginal benefit, if any.
>
> IMO, the ipset package will gain the benefits only when the upstream
> of xtables-addons discontinue
> to merge the ipset as they mention in the changelog and the ipset
> package would be preferred at that time.
>
> > Have you considered joining the xtables-addons packaging team?
>
> I'll happy if I could. :)
>
> > It appears to me that introducing your package would imply work for many
> > people and careful coordination just for the sake of providing the same thing
> > we already have in a slightly different manner.
> >
> > Having said that, I'm not against the idea. Maybe it will be better - I just
> > don't understand the benefits given the overhead for the transition period.
> >
> > What makes you think it worth the effort?
>
> I think, it's a choice for the users. In some cases, users want to use
> only ipset,
> they could definitely install ipset package without the needs to install any
> further kernel modules that they don't use. (no needs to run m-a on
> new kernel upgrade or
> no needs to wait the DKMS to compile the kernel modules)
>
> Despite, if the xtables-addons still build ipset that it's not a problem as both
> packages are conflicted and could not install in the system at the same time.
> Thus, the users who want to use the modules in the xtables-addons
> could still use
> the ipset as well in this case.
>
> Any suggestions ? (Pierre, DDs)
>
> Best regards,
> Neutron Soutmun
>
Reply to: