Calendar files for modified FreeBSD calendar program

[se]

Summary

These are the calendars as currently provided with the calendar program in FreeBSD-CURRENT (SVN rev. 366901)

The purpose of this port is to provide these files independently from the base system, to allow them to be maintained independently from the release cycle, and to make their installation an option.

A possible further refinement is the selection of (e.g. locale specific) subsets of calendars to be installed.

Test Plan

Install patched calendar program (see https://reviews.freebsd.org/D26882 for the suggested patch).
Verify correct results after removal of the calendar files from /usr/share/calendars/.

[se]

Diff updated due to a wrong path (share/calendars instead of share/calendar) that had crept in ...

[imp]

misc/calendar-files/pkg-plist

9 ↗

(On Diff #78531)

This shouldn't be here

[imp]

I can extract history here too, if you want

[imp]

Sorry it took me a day (long story, unrelated to this task), but I have a repo:

https://github.com/bsdimp/calendar

I thought I had permission to create this in freebsd, but alas, I do not. I'll send email to the admins.

I see now your repo has just the data files, while mine has all of usr.bin/calendar. Do you have a preference here? It's 5 minutes to redo it as whatever you want...

[se]

Regarding the history and it being preserved: the repo I created for the calendars was only meant to support allow testing of the port, and I had assumed that you'd want to provide a version with history from an official place (like you did for CTM).

Regarding the question about the full sources or just the calendars being put into this repository:

There does appear not be consensus about what to remove from base:

1. All of usr.bin/calendar?
   • This would require installation of the binary from a port. Not sure whether it is necessary to split it off if from base, given its small size and stability of the sources.
   • If this was the goal, we could have two ports, one for the program and one for the calendar files (both could fetch a common dist file, though).
   • We would probably want to continue to provide calendar.freebsd separately from the other calendar files, but I'm not convinced that this is best done as part of the base system.
2. Just the calendar files sans calendar.freebsd?
   • If the FreeBSD specific data is to be provided only in base, then we could continue to install this one calendar with the installworld.
   • Not sure if we should make LOCALBASE a fall-back location, then, instead of it taking precedence, in order to prevent a potential calendar.freebsd in LOCALBASE to be displayed instead of the one in base.
3. All the calendar files?
   • The port has full control about what data is installed for use with calendar program, and we could find ways to grab and convert calendars from other projects to supplement what we provide.
   • A consequence would be that calendar.freebsd is installed together with all other calendar files, but it could still come from a separate location.

Points to decide [and my opinion]:

• keep the calendar binary in base [yes, it is useful with .calendar files, too]
• patch the calendar binary to include LOCALBASE/share/calendar in its search path [yes, with MFC to -STABLE]
• have LOCALBASE take precedence [yes, to prevent violation of POLA if installing the port does not have any effect until /usr/share/calendar is cleaned up]
• keep calendar.freebsd in base [yes, at least initially, with LOCALBASE being preferred and thus allowing to override it with an updated version from a port]
• provide an optional, patched calendar binary as a port [unsure, this is required to allow -RELEASE users to take advantage of the port before the next release]
• have a common repository with the calendar binary and the calendar data [no, if the patched calendar program is provided as a port, it should have its separate repo, IMHO]

My preference would thus be to

• keep the program in base
• to modify it to prefer LOCALBASE (merged to the stable releases)
• to have the port provide the data files (with freebsd.calendar being generated and distributed separately - but for a start it could remain in base to not disrupt current practices)

The data in calendar.freebsd is special, but having to MFC it to -STABLE (and to possibly distribute an already out-dated version in a release, in case it was modified in -CURRENT late in the release cycle), just does not make sense (if there are good alternatives available).

A port could be created for the binary to allow installation on systems that do not have the updated binary, but TBH, I do not consider the possibility to update the calendar files between releases to be of such an importance for the stable releases (and I'd expect a quick MFC to allow -STABLE users to use calendars in LOCALBASE).
If a calendar binary port existed, it could be made a conditional dependency of the calendar data port, but this port would persist on a system even after upgrading to a new stable version or release that contained the LOCALBASE search in the calendar binary in base. (It could be declared obsolete with a MOVED file entry after all releases have the new calendar binary.)

I'd want to avoid to have 2 separate locations where the calendar binary and the calendar data are maintained (i.e. base and the repo feeding the port) until the day when all releases have a calendar binary that searches LOCALBASE.
Therefore, the calendar files should be removed from -CURRENT and -STABLE as soon as the calendar program is patched, with the exception of calendar.freebsd - the repository used by the port would become the only place where these files are maintained.
Source upgrades would keep the calendar files intact, but if the port was installed, they would be ignored. They should probably be added to ObsoleteFiles.inc at a later date.

misc/calendar-files/pkg-plist

9 ↗

(On Diff #78531)

Yes, I missed the fact that this file is auto-generated and not manually maintained.

[imp]

I think #2 is the best option. I've created https://github.com/freebsd/calendar-data (default branch is presently data, trying to get it fixed to main, but there's also a main branch w/o the removal commit).

I have also hacked in a '#warning' directive that will allow us to create all those files listed here with

#warning calendar.othrodox has moved to ports. Install package with pkg install calendar-data

so we can keep them all in base and observe POLA. The 'L' is least, not 'no'. These message would tell people what broke and how to fix it.

I'd merge the calendar program to stable (all of it), but I'd not merge the calendar files to stable and I'd let what's there rot (though I wouldn't oppose MFCing this too after 12.2 which is building now).

[se]

Fetch from the freebsd/calendar-data repository on GitHub

There currently is no tag to refer to, my suggestion is to tag the current HEAD of the repo as 20201024, which would also become the DISTVERSION of the port/package.

[imp]

I've tagged it as v2020.10. vYYYY.MM seems sufficient. If we get enough updates we can do .1 .2 .3 in addition, but I kinda doubt that will be needed often.

[se]

In D26883#600435, @imp wrote:

I think #2 is the best option. I've created https://github.com/freebsd/calendar-data (default branch is presently data, trying to get it fixed to main, but there's also a main branch w/o the removal commit).

I have also hacked in a '#warning' directive that will allow us to create all those files listed here with

#warning calendar.othrodox has moved to ports. Install package with pkg install calendar-data

so we can keep them all in base and observe POLA. The 'L' is least, not 'no'. These message would tell people what broke and how to fix it.

I'd merge the calendar program to stable (all of it), but I'd not merge the calendar files to stable and I'd let what's there rot (though I wouldn't oppose MFCing this too after 12.2 which is building now).

Since such a warning will be shown once per included file e.g. in the case of calendar.all I suggest an alternative approach, which warns once if a calendar data file from the current (soon legacy) location is displayed, except if this file is calendar.freebsd.

Index: io.c
===================================================================
--- io.c	(Revision 366992)
+++ io.c	(Arbeitskopie)
@@ -84,6 +84,7 @@
 static StringList *definitions = NULL;
 static struct event *events[MAXCOUNT];
 static char *extradata[MAXCOUNT];
+static bool warned;
 
 static void
 trimlr(char **buf)
@@ -124,8 +125,15 @@
 		if (chdir(calendarHomes[i]) != 0)
 			continue;
 
-		if ((fp = fopen(file, "r")) != NULL)
+		if ((fp = fopen(file, "r")) != NULL) {
+			if (!warned && i == nitems(calendarHomes) - 1 &&
+			    strcmp(file, "calendar.freebsd") != 0) {
+				warnx("\"%s\" has moved to ports. "
+				    "Please update with pkg install calendar-data", file);
+				warned = true;
+			}
 			return (fp);
+		}
 	}
 
 	warnx("can't open calendar file \"%s\"", file);

The advantage of this approach is that only one warning is generated (for the first file to be opened if files are included) and that the data files need not be modified.
The same approach with a "warned" variable could of course also be used to limit the number of #warning lines being shown, but that would make #warning even more specific for use in this case.
Then I'd rather introduce a #deprecated tag, which shows the message contained in the program without further text following it.
But these are technical details, and any solution chosen will do ...