Re: Ipfilter pre-Vendor Import Issue

In message <20130708134400.GH67810_at_glebius.int.ru>, Gleb Smirnoff writes:
>   Cy,
> 
> On Fri, Jul 05, 2013 at 11:38:21AM -0700, Cy Schubert wrote:
> C> > What I'd prefer to see is the following:
> C> > 
> C> > - commit new ipfilter untouched to vendor-sys/ipfilter
> C> > - nuke sys/contrib/ipfilter
> C> > - svn copy vendor-sys/ipfilter to sys/netpfil/ipfilter
> C> 
> C> Having ipfilter in one place instead of two (vendor and vendor-sys) makes 
> a 
> C> lot more sense.
> C>
> C> I suppose we could put ipfilter's kernel components in sys/netpfil but wha
> t 
> C> about the userland sources? Also see my reply below regarding keeping it i
> n 
> C> contrib.
> 
> IMO, it is possible to keep a bulk checkout of ipfilter in vendor/ipfilter,
> but merge kernel files separately to sys/netpfil/ipfilter, and separately
> merge userland files to appropriate place.
> 
> C> > In future imports do:
> C> > 
> C> > - commit newer ipfilter to vendor-sys/ipfilter
> C> > - svn merge vendor-sys/ipfilter to sys/netpfil/ipfilter
> C> > 
> C> > What's the reason to keep code in contrib?
> C> 
> C> The reason to keep ipftilter in contrib is to maintain consistency with 
> C> other contributed software such as bind, nvi, sendmail, pf, and a host of 
> C> other notable software we don't maintain ourselves. Maintaining consistenc
> y 
> C> with other contributed software should probably be maintained. I'm open to
>  
> C> moving all packet filters, e.g. ipfw, pf, and ipfilter into sys/netpfil as
>  
> C> long as consistency is maintained across the board.
> C> 
> C> Do you think we should put the userland sources also in the same location 
> C> or should we maintain a similar separation we do today? I'm open to both 
> C> however I'd prefer keeping all vendor software (kernel and userland) in on
> e 
> C> location.
> 
> The BSD license allows us to put the code into FreeBSD w/o any separation.
> 
> So the question is: what is more handy to us?
> 
> What do we actually gain having contrib/ipf, assuming we got vendor branch
> already?
> 
> What we lose is: 
> - more complex Makefiles
> - more complex hacking: edit files in one place, run make in other

How is this for a plan?

Instead of importing the kernel bits into vendor-sys/ipfilter and the 
userland bits into vendor/ipfilter, the base tarball should be imported 
into vendor-sys/ipfilter (or vendor/ipfilter, doesn't matter which). We 
keep the complete tarball imported into one place in the tree.

Merge ipfilter into sys/netpfil/ipfilter (for kernel bits) and 
netpfil/ipfilter (for userland bits).

We should probably think of moving pf and ipfw into the new subdirectory as 
well, but that's for a future discussion.


-- 
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.