Date: Sun, 26 Nov 2017 10:32:56 -0700 From: Ian Lepore <ian@freebsd.org> To: Warner Losh <imp@bsdimp.com> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: The future of fortune(6) Message-ID: <1511717576.23588.47.camel@freebsd.org> In-Reply-To: <CANCZdfp3OrC-GRUXvwCUb-gAW=d=EjTD2nihA31ME0rSwcgs4w@mail.gmail.com> References: <66D39828-ADBA-4973-BEB8-B2F6657E9996@FreeBSD.org> <6ba033f3-82ce-da58-1720-623fed180479@FreeBSD.org> <7326690.xrhihQoxKt@ralph.baldwin.cx> <CANCZdfoRb2ohYRSwYO96R3qujGXMMD2BkL%2BixsE1ZpWkCodTNA@mail.gmail.com> <CANCZdfp3OrC-GRUXvwCUb-gAW=d=EjTD2nihA31ME0rSwcgs4w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 2017-11-26 at 10:16 -0700, Warner Losh wrote: > On Sun, Nov 26, 2017 at 10:11 AM, Warner Losh <imp@bsdimp.com> wrote: > > > > > > > > > On Thu, Nov 23, 2017 at 9:38 AM, John Baldwin <jhb@freebsd.org> wrote: > > > > > > > > On Wednesday, November 22, 2017 03:01:17 PM Kurt Lidl wrote: > > > > > > > > On 11/22/17 11:29 AM, Benno Rice wrote: > > > > > > > > > > I would like people¢s opinion on which of the following two paths we > > > should take: > > > > > > > > > > > > > > > > > > > 1) Complete removal of fortune and freebsd-tips, remove its usage > > > from the default .login/.profile files. > > > > > > > > > > > > > > > > > > > 2) Reworking fortune(6) to remove the offensive fortune flag and make > > > freebsd-tips the default, possibly by symlinking it as > > > /usr/share/games/fortune/fortunes. > > > > > > > > > > > > Of these options, only #2 is approximately correct. > > > > > > > > I think just leaving the code as-is, and symlinking the freebsd-tips to > > > > be the default fortune datafile is the correct course of action. > > > > > > > > Removing the offensive flag handling dictates policy towards users > > > > of the program. If someone wants to add their own offensive datafile > > > > to their system, the code ought to allow them to select it. > > > Agreed. I think removing the default datfiles so that someone can > > > maintain > > > a port is fine, but we should leave freebsd-tips and the tool. When > > > the -o database was moved out of base we didn't remove the -o option, but > > > instead extended the tool to work with string files in /usr/local. The > > > current state is fine. The drama and lost time has always been about the > > > 4BSD datfiles, never about freebsd-tips or the tool itself, so the issue > > > is > > > resolved. > > > > > I like this plan. Let's call it consensus and implement. > > > [[ stupid gmail UI -- hit send too soon ]] > > I call it "consensus" but know there's a number of folks on one end of the > spectrum that want it gone completely, and some on the other end that want > the datafile restored. And all sorts of opinions in between. Maybe "rough > consensus" in that it's about the "centroid" of the mass of opinions on the > topic, and a good argument can be made. > > I find the "freebsd-tips is useful and makes the system more friendly," > argument persuasive. I think it would help our brand and user experience to > have it there by default and it is very much the sort of thing that should > be in the base. Having the "fiunny" data files in a port and having the > tool in the base system is a reasonable compromise, though one that will be > revisited with pkg src in the future so if we get it wrong there's a > natural decision point not too far away. > > Warner I agree that providing freebsd-tips is useful. It also has the nice side effect of not eliminating the program, so that peoples' shell startup scripts won't suddenly start failing because it's missing. I gather from other comments that the current program already knows to look in /usr/local for additional files, so having ports that install just the data files seems like an ideal solution. I think if the program itself were removed from base, we would need to provide a script to cover for it to prevent spurious shell startup failures. The script would have to be something like how pkg(8) in base works -- invoke the /usr/local/bin version if it exists, or tell the user which package to install to restore full functionality. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1511717576.23588.47.camel>