Re: RFS: ipset
I must apologize you, Pierre but I have to CC you because we need your
suggestions.
>> > 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.
>>
>
> My concern is that overlapping is a big source of problems.
> Imagine one have ipset installed - he/she won't be able to use modules
> provided by xtables-addons without uninstalling ipset first, etc.
I agree with you.
>> 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.
>> 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: