Date: Mon, 15 Nov 2021 09:42:16 +0100 From: Rob LA LAU <freebsd@ohreally.nl> To: Guido Falsi <madpilot@FreeBSD.org>, Kurt Jaeger <pi@freebsd.org> Cc: "freebsd-ports@FreeBSD.org" <freebsd-ports@FreeBSD.org> Subject: Re: Adding functionality to a port Message-ID: <455ffbd8-2406-7c75-718c-759da5bab52c@ohreally.nl> In-Reply-To: <e501cb86-9183-af4f-600f-c0fbe91c9c87@FreeBSD.org> 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> <YZFXby/ktthO9Khx@fc.opsec.eu> <bc50a61a-1341-0c70-c427-f1717e2d871a@FreeBSD.org> <c23b8f2e-a2c5-a8e4-1fdd-db2b62404651@ohreally.nl> <e501cb86-9183-af4f-600f-c0fbe91c9c87@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, On 14/11/2021 20:49, Guido Falsi wrote: > You talk about "adding a periodic script". That is not even a real > modification to the upstream software IMHO. Just adding some glue code > for FreeBSD. If the script does what it advertises, and has no malicious > intent I see nothing wrong with it. If it is broken fixing it is the > logical thing to do. Imagine a daemon, an rc script and a periodic script. And imagine that we decided to separate all 3 into separate ports. When fitting these ports into the ports tree, we would make the daemon depend on the rc script, because the daemon needs the rc script to start and stop (and starting and stopping could be considered core functionality). But we would make the periodic script depend on the daemon, because the daemon runs fine without the periodic script, but the periodic script is useless without the daemon. To me this would mean that the daemon and the rc script should be published together as a single port, making the rc script an acceptable FreeBSD-specific addition. (Which does not mean that the addition should not be reported to upstream; the goal should also be to have the rc script included in the upstream project, just like the systemd unit that is already included.) The periodic script, however, should be considered new functionality, and published in a separate port. And to contradict the above, one could now plead that external libraries that the daemon depends on should also be packaged together with the daemon, but the difference obviously is that no other package will ever depend on the daemon's rc script, while those libraries have been created to allow multiple applications to use them. And there will always be exceptions. Things are not always black and white, and they shouldn't be. And obviously, I'm the outsider here. I'm not trying to tell anyone what to do and how to do it. I'm just making sure that this subject has not been overlooked. > Being a son of two lawyers, and having a lot of friends who are lawyers, > and also clients who are law firms, my informed (by having had a lot of > arguments with all these people about this very subject) opinion is that > there is no such thing in the world as a "clear and simple" set of rules. Nobody is trying to write a legal document here. The goal is just to assure that the ports in the ports collection still function as intended by the upstream developers, preferably with no functionality removed, and definitely with no functionality added. Rob -- https://www.librobert.net/ https://www.ohreally.nl/category/nerd-stuff/ https://github.com/ohreally/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?455ffbd8-2406-7c75-718c-759da5bab52c>