[csw-maintainers] bad interactions with CSWcommon

[Philip Brown]

On 7/21/10, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Philip Brown's message of Fri Jul 16 17:43:50 -0400 2010:
>
>> Would you mind doing a little research&inquiry into why specifically
>> the coreutils people provided those symlinks, please?
>
> I'm not going to bother them with this.  I had previously combed
> through the code and there are places where they explicitly set the
> category to LC_TIME though.

Okay, so then you know for a fact that having "LC_TIME" properly
supported, is useful.
 ....


>
>> As in, finding out from them what specifically works, with their
>> links in place, and what breaks,if they are not in place?
>
> This is doing nothing but wasting my time.  I've already read through
> the gettext docs.  The symlinks at the directory level are the wrong
> approach here.


that's your opinion. I have a different opinion.
I am open to listening to further facts on why you have your opinion.
But it seems you are not interested in gathering more facts.



  I'll pose a question for you to research instead.
> What happens if all of the following are true:
>
> 1. CSWcommon continues providing the directory level symlinks making
>    LC_TIME/$foo equivalent to LC_MESSAGES/$foo.
> 2. A package delivers locale files for one of the locales for which #1
>    above is true.
> 3. The package in #2 intends to deliver separate .mo files, which is
>    perfectly withing the gettext specifications.
>

Then I'd be happy to reconsider things.

Given, however, that this has not happened in the (6?) (7?) years i've
been doing this, I'm thinking this is quite unlikely :)

So until either that happens, or you wish to dig up more information
on why coreutils decided on using symlinks instead of separate files
AND that information indicates the current cswcommon behaviour is
bad... current behaviour will stay.  WIth the addition that cswcommon
should be modified to have ALL LC_TIME dirs symlinked, rather than
only partially.