Re: Ipfilter pre-Vendor Import Issue

In message <51DA85CF.3000401_at_freebsd.org>, Andre Oppermann writes:
> On 05.07.2013 20:38, Cy Schubert wrote:
> > In message <20130705084649.GC67810_at_FreeBSD.org>, Gleb Smirnoff writes:
> >> What I'd prefer to see is the following:
> >>
> >> - commit new ipfilter untouched to vendor-sys/ipfilter
> >> - nuke sys/contrib/ipfilter
> >> - svn copy vendor-sys/ipfilter to sys/netpfil/ipfilter
> >
> > Having ipfilter in one place instead of two (vendor and vendor-sys) makes a
> > lot more sense.
> >
> > I suppose we could put ipfilter's kernel components in sys/netpfil but what
> > about the userland sources? Also see my reply below regarding keeping it in
> > contrib.
> >
> >>
> >> In future imports do:
> >>
> >> - commit newer ipfilter to vendor-sys/ipfilter
> >> - svn merge vendor-sys/ipfilter to sys/netpfil/ipfilter
> >>
> >> What's the reason to keep code in contrib?
> >
> > The reason to keep ipftilter in contrib is to maintain consistency with
> > other contributed software such as bind, nvi, sendmail, pf, and a host of
> > other notable software we don't maintain ourselves. Maintaining consistency
> > with other contributed software should probably be maintained. I'm open to
> > moving all packet filters, e.g. ipfw, pf, and ipfilter into sys/netpfil as
> > long as consistency is maintained across the board.
> >
> > Do you think we should put the userland sources also in the same location
> > or should we maintain a similar separation we do today? I'm open to both
> > however I'd prefer keeping all vendor software (kernel and userland) in one
> > location.
> 
> I think the main distinction here is whether the adaptions to
> FreeBSD are kept local (resulting in almost a fork) or are fed
> upstream so that successive updates require less or no local
> changes.

I see no problem feeding update upstream. The email I just received from 
Darren (cc'd Gleb and yourself) is likely to lead to this kind of 
relationship.

> 
> Having the kernel part in sys/netpfil certainly makes it easier
> for kernel people to adjust it to changed realities.

True. I'm thinking we should do the same with the userland side of 
ipfilter, keeping everything consistent.

Also, I think putting all of the vendor bits regardless of whether they're 
destined for kernel or userlan into vendor/ or vendor-sys/ should make it 
simpler as well. What are  your thoughts?

> 
> IIRC ipfilter also has very messy ifdef's all over the place for
> every possible ancient version of FreeBSD.  This probably should
> be cleaned up (and upstreamed) as well.

Yes. There's a lot of cruft in there for operating systems that are no 
longer relevant as well. At least we can push some of the FreeBSD cleanup 
upstream. Initially I'd like to import v5-1-2 into our vendor branch 
(either vendor/ or vendor-sys/ for the complete tarball) then svn merge 
into sys/netpfil/ (for kernel) and netpfil/ (for userland).

Do you have any additional thoughts on any of this?


-- 
Cheers,
Cy Schubert <Cy.Schubert_at_komquats.com>
FreeBSD UNIX:  <cy_at_FreeBSD.org>   Web:  http://www.FreeBSD.org

	The need of the many outweighs the greed of the few.