From owner-freebsd-current@FreeBSD.ORG Mon Jul 8 20:00:10 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AF568E2B; Mon, 8 Jul 2013 20:00:10 +0000 (UTC) (envelope-from Cy.Schubert@komquats.com) Received: from smtp-out-01.shaw.ca (smtp-out-01.shaw.ca [64.59.136.137]) by mx1.freebsd.org (Postfix) with ESMTP id 7D278169B; Mon, 8 Jul 2013 20:00:10 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=dWI+KISfqi6yXfbrXJvRDWIsIl/dscdoFNN/P4RSWeA= c=1 sm=1 a=uK1SP89eXToA:10 a=QrugwKR0C_UA:10 a=wAGQQ9Az6v0A:10 a=BLceEmwcHowA:10 a=ICAaq7hcmGcA:10 a=kj9zAlcOel0A:10 a=IbtKDeXwb2+SRU442/pi3A==:17 a=mR7p8zZ_AAAA:8 a=BWvPGDcYAAAA:8 a=6I5d2MoRAAAA:8 a=85G9OQlxTEjs4HCS67sA:9 a=CjuIK1q_8ugA:10 a=V7tsTZBp22UA:10 a=SV7veod9ZcQA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([96.50.7.119]) by smtp-out-01.shaw.ca with ESMTP; 08 Jul 2013 14:00:03 -0600 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTP id 0FF51D2; Mon, 8 Jul 2013 13:00:03 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.7/8.14.7) with ESMTP id r68K02Ef063517; Mon, 8 Jul 2013 13:00:02 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201307082000.r68K02Ef063517@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.5 From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: Gleb Smirnoff Subject: Re: Ipfilter pre-Vendor Import Issue In-Reply-To: Message from Gleb Smirnoff of "Mon, 08 Jul 2013 17:44:00 +0400." <20130708134400.GH67810@glebius.int.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 08 Jul 2013 13:00:02 -0700 Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Cy Schubert List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 20:00:10 -0000 In message <20130708134400.GH67810@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 FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few.