Re: [RFC][PATCH v5 00/13][BZ 10871] Month names in genitive case

[Florian Weimer <fweimer at redhat dot com>]

On 12/30/2016 12:53 AM, Rafal Luzynski wrote:
> 29.12.2016 17:42 Zack Weinberg <zackw@panix.com> wrote:
> > [...]
> > I think you should just go ahead and change the behavior of %B
> > unconditionally. Preserving the old behavior for old binaries is,
> > IMNSHO, more likely to preserve existing bugs than to fix bugs.
>
> I'd like to agree: backward compatibility code introduces lots of
> mess IMO, it indeed looks like an attempt to preserve an existing
> bug, and with time it will become less and less useful while will
> probably remain in sources forever.  Skipping it is easy: my change
> is split into multiple patches so if you don't want the backward
> compatibility then you just skip those two patches, or actually
> four patches counting *.abilist rebuilds, and here it is.
>
> But the backward compatibility has been explicitly required
> here: [1] and in follow-ups like [2].  The argument for it is that
> some applications (calendars, I can't imagine anything else)
> may need the months names in nominative form, which is currently
> provided.  Here is an example of a calendar using genitive
> form instead of nominative: [3].

> [1] https://sourceware.org/ml/libc-alpha/2016-06/msg00009.html
> [2] https://sourceware.org/ml/libc-alpha/2016-06/msg00019.html
> [3] https://sourceware.org/ml/libc-alpha/2016-11/msg00392.html

These comments were based on your own presentation of the issue, and not 
independent research, so they are flawed.

If this was a bug fix, it should apply to old binaries as well.

The problem is that your approach breaks about as many usage scenarios 
as it fixes, and I'm still puzzled why you continue to push for this 
approach.  A 100% backwards-compatible alternative exists, so why not 
use it?  True, a future POSIX update may break backwards compatibility, 
but that's a POSIX bug in the making, and not something we should follow 
blindly.

Thanks,
Florian