Date: Tue, 20 Oct 2020 14:54:20 +1100 From: Greg 'groggy' Lehey <grog@FreeBSD.org> To: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Modernizing calendar(1) (was: svn commit: r365984 - head/usr.bin/calendar/calendars) Message-ID: <20201020035420.GA59361@eureka.lemis.com> In-Reply-To: <CANCZdfpWcwt2gSF5m3_Z2DfBmURpk-UCeOfvFN8H_C8SQu_8WA@mail.gmail.com> References: <20200923134334.czblcl2ppyxjnigs@mutt-hbsd> <CANCZdfpWcwt2gSF5m3_Z2DfBmURpk-UCeOfvFN8H_C8SQu_8WA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This discussion, from a month ago, seems to have died a death. First I'll summarize what imp@ says: On Wednesday, 23 September 2020 at 9:18:27 -0600, Warner Losh wrote: > > 1. I'll do for calendar what I did for CTM. We'll split it out into its own > git repo. git filter-patch is straight-forward to use, but has a number of > caveats with the imperfect github mirror we have. I'll do it against the > beta cgit mirror and write up the process since I'm pretty sure people will > want to replicate it in the future. > 2. Delete the contentious bits (details to follow) > 3. Adjust the build (since calendar uses cpp to build up its databases) > 4. Prune the new repo to just the contentious bits into that repo (likely > under github.com/freebsd/calendar, like we've done for CTM and other things) > 5. Create a port you can optionally install > 6. Adjust calendar to work when things are there (or not there) > 7. Remove the contentious bits from FreeBSD... This shows the procedural approach. But what do we really want? I think that we should agree that we don't want to remove functionality, just bring things into the 21st century. As I see it, there are three approaches: 1. Nobody cares enough about it, so leave it as it is. Given the lack of input on the subject, this might be the best choice. It's certainly the easiest. But it leaves a lot of dead wood and unbalanced and incorrect content. 2. Move the non-FreeBSD related stuff into a port. This is imp@'s approach above. As you can see, it's rather involved, and it seems to me that we shouldn't be doing this sort of thing until we've moved the project to git and the dust has settled. It also complicates maintenance, and it doesn't address the dead wood and dubious content. 3. Create a separate port that sucks in and maintains suitable calendar entries from *somewhere* and maintain a directory hierarchy, say /usr/local/calendar, in the same form as the current /usr/share/calendar. Modify the calendar(1) in the tree to look at this hierarchy as well. /usr/share/calendar should remain for the few FreeBSD-related files (as far as I can tell, only calendar.freebsd). 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. Greg -- Sent from my desktop computer. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20201020035420.GA59361>