Re: RFS: ipset
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
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: