Re: Adding functionality to a port

NOTE replying with my FreeBSD.org address to make the reply reach the 
mailing list, sorry my previous messages on this thread bounced.

On 14/11/21 19:37, Kurt Jaeger wrote:
> Hi!
> 
>>>> It is also not correct to "commandeer" a port to force users on design
>>>> choices in conflict with the upstream project.
> 
>>> Is there a section in the ports maintainers guide or somewhere
>>> else that mandates this ?
> 
>> Sorry, my fault I did not make me clear maybe, this is all my own opinion.
>> So is what follows.
>>
>> Anyway I don't see it as a good beahviour to take a port of some upstream
>> software and move it in a contrasting direction than the upstream.
> 
> I agree. The problem is that this is very difficult to codify
> into some policy.

Very difficult, and I'd really would like to avoid to make the FreeBSD 
project documents some kind of legal codex.

> 
> [...]
>> The name "ports" implies it is not the place for original development. I
>> also agree we often have a disconnection on how things are named and what
>> they actually are or behave, so I would not have any strong reply if you
>> were to state the the name cannot be held as a reason for policy.
> 
> So some sort of rule might be: If the functionality varies from
> the upstream-project in a major way, please use a derived or different
> name for the port.
> 

As I stated in another (provate message) I just realized that this is at 
least partly covered by "POLA". IN fact I would very astonished if some 
port (say firefox for example) started behaving very differently than it 
does on other OSes for no good technical reason.

OTOH a valid technical reason could be dropping some functionality 
depending on some API not available on FreeBSD, just to make an example 
from the top of my head.

-- 
Guido Falsi <madpilot@FreeBSD.org>