From nobody Mon Nov 15 09:21:46 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E8EAD1854673 for ; Mon, 15 Nov 2021 09:21:48 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ht3bw6CbKz3PnL; Mon, 15 Nov 2021 09:21:48 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Received: from [172.24.42.13] (host-79-51-17-182.retail.telecomitalia.it [79.51.17.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: madpilot/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 518CC22C80; Mon, 15 Nov 2021 09:21:48 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Message-ID: <0415769b-ac3d-86d0-54c4-1f0a74db0b13@FreeBSD.org> Date: Mon, 15 Nov 2021 10:21:46 +0100 List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Subject: Re: Adding functionality to a port Content-Language: en-US To: Rob LA LAU , Kurt Jaeger Cc: "freebsd-ports@FreeBSD.org" References: <4ca51765-b556-3f12-5809-5aadbf6dccca@ohreally.nl> <480b44f5-0674-e645-8413-a1a368cfc393@ohreally.nl> <455ffbd8-2406-7c75-718c-759da5bab52c@ohreally.nl> From: Guido Falsi In-Reply-To: <455ffbd8-2406-7c75-718c-759da5bab52c@ohreally.nl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N On 15/11/21 09:42, Rob LA LAU wrote: > 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. > I don't follow you. The example is too abstract for any useful purpose. You intentionally mix the concept of "depending on" with the concept of "packaging together". Even following your example all the practices you describe could be acceptable and at the same time debatable. The variety of software is too broad to create a strict rule set. Such matters need to be handled on a case by case basis anyway We do have some principles to guide us, which have been stated to you. One of these is classic POLA, for example. This gives us an idea. You have to consider how the original software is packaged upstream and usually packaged for other OSes. Considerable differences from the rest of the world best practices would be "astonishing". Also you have to consider upstream documentation. If that suggests doing things in a certain way and the port did things in a different way that would be astonishing too. In the end you also seem to forget or intentionally ignore that FreeBSD is also a community of developers and users. You do things the best you think, but it can happen that users or other developer will tell you you are wrong, maybe suggesting better solutions. Ideally this is done in a polite and constructive way; unluckily it sometimes gets aggressive and unpleasant, and this is definitely something we should avoid. You can then modify your work and make it better based on this feedback., No technical choice is set in stone. >> 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. You look too worried by the "functionality added" part. If the added functionality is only a script needed for integration with the system it's not added, but something strictly needed by the porting effort. For example I maintain some ports (asterisk, ntopng) which are run as daemons. Upstream does provide startup scripts for linux, but none for FreeBSD. The ports contain startup script I made because they are needed for proper usage of the port. (and some bugs have happened in those scripts, I have fixed those to the best of my ability) Users are not force to use the startup script I (or upstream for that matter) provides. They are disabled by default. Nothing stops the users from writing their own rc scripts, or using a different method of starting them (cron @reboot or something like supervisor for example). Those scripts are "added" but not mandatory for anyone, they don't detract anything from the upstream software. I don't know which port periodic script you are talking about, but I guess it's not enabled by default, and in the unfortunate case the maintainer went out of his way to make it such, it should be possible to disable it, and then you can script your own or use something else for that part of the port. This for startup and rc scripts...other more convoluted cases require case by case analysis. A more general reply is impossible. -- Guido Falsi