RFC: Tripwire name change

[Keith G. Robertson-Turner]

On Sun, 22 Feb 2004 09:35:38 -0500, Mike A. Harris wrote:

> On Sun, 22 Feb 2004, Keith G. Robertson-Turner wrote:
> 
>>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.
> 
> That would not work because then every single time a new rpm package is
> built, one would have to edit specspo to update all the version numbers.

Which is exactly why the centralised system, that specspo employs, doesn't
work. Packages should contain their own translation (including the package
summary and description). The translation is done once, as it is now, by
whoever it is that is responsible for such things (i18n.redhat.com?), and
merged with the SRPM by the build process. If the packager changes either
the summary or description (albeit once every ten years), then he either
has to wait for translation (BLOCKER) or publish without translation. In
this way, the summary and description is always up to date, although maybe
sometimes only available in one language, depending on what stage the
translation is at. I'd rather have an accurate description in one
language, than a (perhaps dangerously) misleading or out of date
description in twenty.

> Since the description text is something that rarely if ever changes in
> most packages

Rare, yes, but should it happen at all ... ever ... if there is a better
way. This is not the slow, steady release of Red Hat boxed sets era, this
is the fast and furious, new kernel a week, 20 new packages a day, apt
repo's springing up like mushrooms, era. Specspo is based on an assumption
... that, basically, package summaries and descriptions never change, and
that the package base remains static. This is wrong. Specspo is broken,
and in the worst possible way, in a way that simultaneously breaks (or
potentially breaks) every other package in a distro (in however trivial a
manner).

> having to manually update specspo every time would not be very
> convenient.  It would be annoying to the point that developers would
> probably refrain from building packages as often, and instead wait much
> longer between updates to avoid the specspo update penalty.

I think you're putting the cart before the horse. Packagers would release
as often as they liked. *If* and *when* translations became available,
then they would be merged in by the build process ... until then, the
package would remain un-translated. Unless the packager him/her-self
decided to BLOCK while awaiting translation (or seek assistance from
elsewhere to do the translation).

The point is, let's get away from monstrous, centralised, totalitarian
methods, and employ distributed, modular, flexible methods instead.

> Since we do not ship tripwire anymore, and haven't since RHL9, if it
> isn't already removed from specspo, it would make a lot of sense for us
> to remove it IMHO.

Might as well, since the "translations" for it are not translations at
all, but just the original text copied verbatim.

> /me who hates mixed case package names, including XFree86

/me too ;'