Re: Ipfilter pre-Vendor Import Issue

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.

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

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.

-- 
Andre