[csw-maintainers] bad interactions with CSWcommon

[Philip Brown]

On 7/25/10, Ben Walton <bwalton at opencsw.org> wrote:
>
> I on the other hand have read the gettext docs, an action which I
> think is more germane to the issue than pestering the coreutils folks
> about their specific use of gettext.

I see that you didnt seem to want to "bother" them about why they are
doing what they do,
but you seem fine bothering them to ask an opinion about what I'm doing.
This seems inappropriate to me.


>...
>> Given, however, that this has not happened in the (6?) (7?) years i've
>> been doing this, I'm thinking this is quite unlikely :)
>
> It has happened now.  CSWcoreutils is using the gettext system in a
> valid manner and your actions in CSWcommon have caused a conflict. A
> symlink is a separate file.

No it is not a "file". it is a symlink. I chose my words very specifically.
While what you say is true in the context of OS implementation, we're
talking about packaging.
In the context of packaging, a file is not a symlink.
"s" vs "f", after all.



>> 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.
>
> Why short change the system here?  What makes LC_TIME more special
> than LC_NUMERIC and the other various categories?

Go ask the coreutils people that first, why THEY decide to add a
symlink for it, and thus *they* think LC_TIME is "more special than
LC_NUMERIC and the other various categories".
You've already seen fit to bug them once already now.
You seem to think their opinion is more valid than mine here; so then,
ask them their opinion on why THEY think this also!


Meanwhile, I'm updating common to at least be consistent with the
symlinks, as I said i would.