[csw-maintainers] bad interactions with CSWcommon

[Philip Brown]

On 7/9/10, Ben Walton <bwalton at opencsw.org> wrote:
> Excerpts from Philip Brown's message of Fri Jul 09 15:02:18 -0400 2010:
>
> Hi Phil,
>
>> Research should look into WHY some locales have the symlinks for
>> LC_MESSAGES == LC_TIME, and some do not.
>
> I suspect that you added symlinks in CSWcommon for the locales
> delivered by the packages that were broken and no other locales.  That
> makes sense given what you were attempting to do.
>


well, trouble is, we no longer know definitively what I was
"attempting to do" :-}


>>[Phil wrote]
>> Even in the package of your "own" that you are complaining about:
>> some symlink, and some do not.

Actually, I just looked in coreutils again.

and... it's inconsistent.
for example, it provides

1 d none /opt/csw/share/locale/nb 0755 root bin
1 d none /opt/csw/share/locale/nb/LC_MESSAGES 0755 root bin
1 f none /opt/csw/share/locale/nb/LC_MESSAGES/coreutils.mo 0644 root
bin 29201 33503 1277688854
1 d none /opt/csw/share/locale/nb/LC_TIME 0755 root bin
1 s none /opt/csw/share/locale/nb/LC_TIME/coreutils.mo=../LC_MESSAGES/coreutils.mo

but only
1 f none /opt/csw/share/locale/lt/LC_MESSAGES/coreutils.mo 0644 root
bin 38282 41078 1277688854
1 d none /opt/csw/share/locale/lt/LC_TIME 0755 root bin
1 s none /opt/csw/share/locale/lt/LC_TIME/coreutils.mo=../LC_MESSAGES/coreutils.mo


(no 'd' entry for the lt directory itself. Erm.. that's because of
deduplication with
  cswcommon, I suppose? But still, inconsistency==not good)

Yes I realize the irony of me saying that, given cswcommon.  I WOULD
like consistency there also. Trying to think of ways to get there.

It would appear, that my initial glance and claim that coreutils only
symlinked SOME
LC_TIME entries, was incorrect. It seems to me note, that it symlinks
ALL of them.

I also think it likely that cswcommon was, as you say, tracking the
locales from coreutils predecessors.

Given these "new" facts, I'd like to make the following proposal,
similar to the one you made:

1. cswcommon gets updated, to symlink ALL LC_TIME dirs to LC_MESSAGES
2. cswcommon gets a README file mentioning that the reason for the
LC_TIME links,
    is to track coreutils local stuffs (and that as more locales get added, more
    dirs and LC_TIME symlinks should be added to it)

3. coreutils then gets to skip its LC_TIME symlinks.

Hmm. there should probably also be a reverse comment in coreutils,
 "If new locales pop up that are not in cswcommon, then cswcommon
should be updated".
It might even be nice to have an AUTOMATED check, for "Hey, new
locale! update cswcommon!"