Re: RFS: ipset
On Thu, Jan 19, 2012 at 10:08 AM, Henrique de Moraes Holschuh
<hmh@debian.org> wrote:
> On Thu, 19 Jan 2012, Dmitry Smirnov wrote:
>> > > 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.
>
> ipset is distributed separately upstream, it has its own life upstream
> (and git tree, etc), and all the functionality it requires is already
> upstream (kernel). Related functionality (iptables) is also upstream.
>
> I'd actually ask why should ipset be packaged together with the rest of
> the stuff in xtables-addons, which is composed mostly of stuff that did
> not achieve upstream (as in kernel/iptables) inclusion yet for whatever
> reason?
>
>> > 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.
>
> ...
>
>> > 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. :)
>
> Indeed. alternatives are not for this kind of use.
>
>> > Or ipset source package should build only libipset{2,-dev} and leave
>> > the ipset utility in xtables-addons as before.
>
> That's a Bad Idea[tm]. Very bad, in fact.
>
>> 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.
>
> Here is one DD commenting, with his "I do use this stuff at work" hat on,
> and >10 years experience both as a Debian developer and sysadmin:
>
> IMO it should be shipped separately, it has a separate life upstream and
> it has been mainlined in the kernel and iptables side so it is now an
> standard feature of an up-to-date Linux-based system.
>
>> 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.
>
> I feel we could well wait a few weeks to get this done properly.
>
>> 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.
>
> To me, a separate ipset package does have advantages:
>
> 1. Ease of backporting.
>
> 2. No need to install stuff not yet ready/accepted on the kernel
> upstream/ipstables upstream to get standard stuff (ipset) to work.
> ipset is the kind of utility you install on routers and firewalls,
> where the less unused stuff, the better.
>
> 3. Reflects the reality upstream.
>
> It does have an one-time drawback: the work required to remove/disable
> ipset from xtables-addons*.
>
>> What makes you think it worth the effort?
>
> Well, FWIW, I do think it is worth the effort. In fact I have a half-done
> ipset package somewhere, which apparently I won't have to finish and take
> care of now that someone else stepped up to do it :-p
Thanks for your comments Henrique, they make sense.
Also, it would be great to have this stuff ironed out for the Wheezy
freeze (perhaps coming in June.)
-Matt Zagrabelny
--
"This space was intentionally left blank as to not advertise to you
what cellular provider nor what iDevice was used to send you an
email."
Reply to: