Re: RFC: Tripwire name change

["Warren Togami" <warren togami com>]

> 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