cvs commit: ports/security/sshguard Makefile

[Mij]

On 02/mar/07, at 19:53, Kris Kennaway wrote:

> On Fri, Mar 02, 2007 at 07:49:42PM +0100, Mij wrote:
>>
>> On 02/mar/07, at 17:49, Kris Kennaway wrote:
>>
>>> On Thu, Mar 01, 2007 at 10:06:14AM +0000, Cheng-Lung Sung wrote:
>>>> clsung      2007-03-01 10:06:14 UTC
>>>>
>>>>  FreeBSD ports repository
>>>>
>>>>  Modified files:
>>>>    security/sshguard    Makefile
>>>>  Log:
>>>>  - respect maintainer's insist on interactive part,
>>>>    even IS_INTERACTIVE is discouraged
>>
>> not glad to see such comment
>>
>>
>>> This is disappointing.  Can the maintainer explain why?
>>
>> the app requires the user to choose what firewall to support for
>> building: IPFW or PF.
>> They are in XOR and there is no reasonable default in this.
>>
>> Cheng-Lung chose PF default and removed is_interactive.
>> A feedback request would have avoided this qui pro quo.
>
> IS_INTERACTIVE should *never* be used when there is a possible
> alternative.

please include this dogma at some point in
http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/


> The obvious choice here (if you really cannot decide on
> a default) is to make your port in two variants, one a slave of the
> other, which enable either option.

I see three possibilities

*) defaults
do we have any data showing that PF (or IPFW) covers 95%+ of the users?
or do we have any other reason to say that defaulting to PF (or IPFW)  
will work
on all/most setups?
If we don't, no defaults make sense

*) variants
while this seems the best approach, new protection mechanisms will  
appear
in the future. This would bring a lot pollution of security/sshguard- 
* variants
in the long run. E.g., version 1 has two more backends underway.
Moreover, a default could actually happen in the future, one  
mechanism that works
on all setups given some other compromise (e.g. hosts.allow).

*) autodetection
the port could check itself for what backend to use. E.g. look in / 
etc/rc.conf
for pf_* or firewall_* . If none of the possibilities are detected,  
however, the
problem falls back to the one of defaults.


In the end, I think this port requires interaction.

If some of you has more suggestions, they are welcome.

In the meantime, as we've come to subtle details of the port, I will  
stop copying
to cvs-* people for the next messages.

bye
mm


>>> And what is this? :)
>>
>> this used to be ".error blah"  for checking the options' XOR-ness,
>> then removed because
>> options are also set when deinstalling/cleaning etc. Definitely
>> useless, replacing with a
>> comment about the problem appears the best to do. Actually I dunno
>> why this made its way
>> in the submission :)
>
> OK, I assume you'll fix this?
>
> Kris