[csw-maintainers] bad interactions with CSWcommon

[Ben Walton]

Excerpts from Philip Brown's message of Fri Jul 23 20:47:29 -0400 2010:
> > 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.
>  ....

Right.  The key word here is properly.  I'm aiming for a solution that
is both functional _and_ future proof.  The proposal is also in the
spirit of how gettext is intended to work.

> >> 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.

What are you talking about?  I'm the only one that has brought facts
into this discussion.  You're resorting to hand-waving, undefined
references to vague memories of why you added these links and
decisions by fiat.  (Sadly the third is expected behaviour...the first
two are what I find out of character here.)

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.  After all, we're discussing a
gettext problem here, not a coreutils problem.  The coreutils package
simply brought to light the error.

Have you, by the way, read the gettext docs?  Recently?

I've clearly outlined why your solution is wrong, why it hasn't yet
harmed anything and why my proposed solution is better technically.
(That is in addition to being less work overall, btw.)

You seem stuck on the fact that providing symlinks at the directory
level is somehow going to magically improve the gettext capability of
all packages.  It won't.

It only 'fixes' packages which have a defect in that they set a
category for gettext and then fail to provide .mo files there.  This
is a package bug.  In every day use though, it's no different than
when a program is only partially translated.  Programs don't crash
when you set the locale to a value for which your app hasn't provided
.mo files...regardless of the category.

> > 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 :)

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.  The directory level symlinks prevent a
package from delivering files in a manner consistent with what gettext
allows for.

> 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?

Your argument is flaky.  It's like saying: I know this function has a
segfault but nobody calls this function with arguments that trigger
the crash.  I'm not fixing the segfault...

Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302