Modernizing calendar(1) (was: svn commit: r365984 - head/usr.bin/calendar/calendars)

[Stefan Esser]

Am 21.10.20 um 03:23 schrieb Greg 'groggy' Lehey:
[...]
> That's the whole point.  Where do we draw the line?  Given that these
> holidays interest more people outside the project than in, I'd think
> that they should all go into the port.  And the whole idea of
> alternative 3 is that the maintenance should be automatic and
> external, so updating holidays should no longer be our concern.

Are we taling about the calendar binary or the calendar files?

IMHO, the calendar binary could stay in base but be modified to
scan directories in e.g. /usr/local/share/calendar/ and ports
could provide these calendar files.


A trivial patch is included below that allows for just this
change to become effective, and I'd like to commit it to -CURRENT.


>>>     This would be my preferred approach.  The issue is identifying
>>>     *somewhere*.  I've done a bit of searching on the web, and I've
>>>     found lots of "on this day" sites, but nothing that would easily
>>>     lend itself to conversion to calendar(1) files of the kind I'm
>>>     looking for.  Input here would be welcome.
>>
>> Ah, that's a second problem. But let's not get bogged down in
>> solving that and then fail to do the split properly.
> 
> I don't understand your haste in wanting to do this.  Until we don't
> know what we're going to do, we can't do the split properly.  We've
> had calendar since the beginning of time, and suddenly it seems to
> need changing.  Let's agree on what we want to do first.

We could easily create a port containing all the files from
src/usr.bin/calendar/calendars except for calendar.freebsd
(and perhaps calendar.computer ?), which could remain in base
together with the binary.

I'd be willing to prepare a port that provides these calendar
files (with config options to select indiviual calendars, if
found useful).

> In the meantime, though, something else has occurred to me: at least
> get buy-in from the other BSD projects.  I've just checked NetBSD,
> OpenBSD, Mac OS and Ubuntu (I think) Linux, and they all have the same
> structure.  They also all have the same error that I fixed in FreeBSD
> a couple of days ago.  I'm pretty sure that they're in the base system
> for the first three, since they're from a virgin installation.  My
> guess is that they're also in the base system for Ubuntu, or whatever
> version I have access to.

If the calendar binary remains in base, there is no need to
check with other projects. In fact, they might find it easier
to follow us and provide separately maintained calendar files
that are not bound to a distribution or single project, too.

> This issue is not important enough to take a knee-jerk approach.  I'd
> rather see something that all the projects can use.  In this
> connection, of course, GitHub sounds like a good potential start, but
> would the OpenBSD project (for example) buy in to it?

The hosting of calendar files and the method used to let the
community contribute to them are technical details.



If there are no strong objections, I'd want to apply the following
change to usr.bin/calendar:

Index: io.c
===================================================================
--- io.c	(Revision 366901)
+++ io.c	(Arbeitskopie)
@@ -71,7 +71,7 @@
  };

  const char *calendarFile = "calendar";	/* default calendar file */
-static const char *calendarHomes[] = {".calendar", _PATH_INCLUDE}; /* 
HOME */
+static const char *calendarHomes[] = {".calendar", _PATH_INCLUDE, 
_PATH_INCLUDE_LOCAL}; /* HOME */
  static const char *calendarNoMail = "nomail";/* don't sent mail if 
file exist */

  static char path[MAXPATHLEN];
Index: pathnames.h
===================================================================
--- pathnames.h	(Revision 366901)
+++ pathnames.h	(Arbeitskopie)
@@ -34,4 +34,9 @@

  #include <paths.h>

+#ifndef _PATH_LOCALBASE
+#define _PATH_LOCALBASE "/usr/local"
+#endif
+
  #define	_PATH_INCLUDE	"/usr/share/calendar"
+#define	_PATH_INCLUDE_LOCAL	_PATH_LOCALBASE "/share/calendar"

The definition of _PATH_LOCALBASE should go into /usr/include/paths.h
and it could also be used in the definition of _PATH_DEFPATH (which
currently contains a verbatim "/usr/local" in two path elements) in
that file.


The above patch is sufficient to let a port provide the identical
calendar files currently installed in base (and I have prepared a port
that does exactly this except for calendar.freebsd) - but obviously
no commit is planned without the above shown extension to the binary
to check for the additional path in LOCALBASE.

Regards, STefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20201021/d931077c/attachment.sig>