The future of fortune(6)

[Ian Lepore]

On Sun, 2017-11-26 at 10:16 -0700, Warner Losh wrote:
> On Sun, Nov 26, 2017 at 10:11 AM, Warner Losh <imp at bsdimp.com> wrote:
> 
> > 
> > 
> > 
> > On Thu, Nov 23, 2017 at 9:38 AM, John Baldwin <jhb at 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