On Sun, 22 Feb 2004 01:12:51 -0500, Bill Nottingham wrote:
> Keith G. Robertson-Turner said:
>>
http://bugzilla.fedora.us/show_bug.cgi?id=1308
>
> Specspo needs to die... the out-of-band nature of it is bad.
>
> Unfortunately, there's not anything better yet.
As I stated on bugzilla, the whole specspo thing was new to me. In fact I
was rather shocked to be confronted by that sort of behaviour, which is
almost Virus-like.
Being an English native speaker, I have the luxury of not really having to
think about "human language" issues on computers, since nearly all
software on all platforms has documentation and buttons/popups/menus etc
in English, if no other language (although I have noticed the very
occasional exception).
I remember (being an ex-Amigan) that the Amiga Workbench "Locale" system
was very neat and easy. In fact I'm running (the new updated) UAE here now
(thank you Richard Drummond), and I'm reminded of how simple but effective
it really is. One "assign" to "Locale:", which then contains
Catalogs,
Countries, Languages, Providers, Flags and Help (oh sorry another assign
... to "HELP:"). The developer/maintainer of each app was responsible for
providing its translation catalog, and that was that. If it didn't come
with translations, often you would find someone else had already done it,
and uploaded the tiny archive containing the translation catalog to
Aminet. (Side note and shameless plug: I've packaged UAE and it's in the
QA queue on fedora.us).
The idea of having one huge behemoth file (Windows Registry style) for
locale translations, is abhorrent, and I must say, very un-Linux. At the
very least, the catalog entries should have been hard locked to a specific
version of each package, that way if the versions don't match, then the
contents of the specspo catalog are ignored. That particular omission is
what amazes me most ... it defies belief, but then I guess that's an RPM
bug, not specspo which is, after all, only data files.
Anyway, I'll wait a few days, then if there are no major issues, I'll go
ahead and change the name of the Tripwire package (actually it's done
already, I just haven't posted to bugzilla yet).
It seems like an extremely ugly way to avoid the specspo problem. If this
package needs a name change to avoid it, that would mean that this is an
acceptable solution for other packages too. There MUST be a better way.
Perhaps...
BuildConflicts: specspo
Conflicts: specspo
... Yeah I am half kidding... but you think of a better solution.
Warren