svn commit: r367103 - head/usr.bin/calendar

[Warner Losh]

On Wed, Oct 28, 2020 at 9:09 AM Stefan Esser <se at freebsd.org> wrote:

> Am 28.10.20 um 14:34 schrieb Kyle Evans:
> > On Wed, Oct 28, 2020 at 8:24 AM Stefan Esser <se at freebsd.org> wrote:
> >> I'm thinking about support for nested conditionals and #else in
> >> calendar files, but I'm not sure about the possibility to MFC
> >> such a change and I do not want to invite users to create calendar
> >> files that work in -CURRENT but not in -STABLE.
> >
> > Unsolicited $0.02: Do whatever you feel comfortable with. It's up to
> > people trying to use the new/advanced features to make sure it's
> > compatible with the calendar(1) that *they* are using, and I'm having
> > a hard time imagining folks using deploying additional calendar data
> > in ports outside of deskutils/calendar-data which you can curate for
> > stuff like that.
>
> I only read your reply after committing the change that allows for
> recursion.
>
> The issue reported by Julian H. Stacey on the freebsd-stable list
> made me check for the code that implements these conditions, and
> I noticed that there was no #ifdef (which he had tried to use),
> but it was trivial to implement.
>
> The man-page mentions that a restricted subset of CPP directives
> is supported, and ISTR that an earlier version of the calendar
> program actually forked CPP to pre-process the data files.
>
> This approach required a "traditional" CPP that ignored the content
> of the non-directives being processed, which is no longer available.
>
> In a way I'm removing some of the limitations that resulted from
> the switch to an internal parser for the conditions.
>
> If there is consensus not to introduce any new features into our
> calendar program, then I'm going to revert these changes.
>
> I had planned to give time for a discussion about a possible
> merge to -STABLE.
>
> I have already created a port of the calendar program as
> deskutils/calendar and was planning to upgrade the port to include
> these changes in -CURRENT.
>
> The port could be used to provide release users with these features,
> if they consider them useful.
>
> Since the changes are fully compatible with old data files, I do
> not think that a MFC was a violation of POLA.
>
> We do now have the calendar-data port for use in -CURRENT and it
> could be used to distribute calendar files that use the new features.
>
> Since old calendar programs will not look into the port's data file
> directory, they will continue to operate on files in the base
> system.
>
> If the calendar program from a port is used, it will support the
> features of this version and that all calendar files that take
> advantage of them.
>
> We might hide these new features by removal from the man-page or we
> could discourage their use by declaring them unportable extensions.
>

Honestly, I think MFCing what we've committed to date and requiring
calendar-data is fine. POLA isn't violated because you have to install a
new port, especially when the program that 'fails' includes that in its
failure message. It's the least bad solution, and calendar isn't a critical
part of the infrastructure where we have to make herculean efforts to hide
any changes. It beats the old files rotting in stable.

Warner