Date: Sun, 14 Nov 2021 19:37:35 +0100 From: Kurt Jaeger <pi@freebsd.org> To: Guido Falsi <mad@madpilot.net> Cc: freebsd-ports@freebsd.org Subject: Re: Adding functionality to a port Message-ID: <YZFXby/ktthO9Khx@fc.opsec.eu> In-Reply-To: <e07b5a48-3465-c92b-ee4b-f2fc91e0202f@madpilot.net> References: <4ca51765-b556-3f12-5809-5aadbf6dccca@ohreally.nl> <YZEskkPi2%2BcX9hrZ@home.opsec.eu> <480b44f5-0674-e645-8413-a1a368cfc393@ohreally.nl> <YZExLlXP3uEjrvyF@fc.opsec.eu> <fb5e514d-1458-9b49-1882-b64d5386cdfa@madpilot.net> <YZFGCoblQOHPnPWe@fc.opsec.eu> <e07b5a48-3465-c92b-ee4b-f2fc91e0202f@madpilot.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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. [...] > 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. -- pi@FreeBSD.org +49 171 3101372 Now what ?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YZFXby/ktthO9Khx>