rpm-5.4.16-0.20160321.src.rpm, take 3

[Jeff Johnson]

On Apr 24, 2016, at 10:25 AM, Jeff Johnson wrote:

...

> 
> I think that I18N could (and should) be done better in RPM. Meanwhile devising a transparent
> "legacy compatible" retrofit for RPM_I18NSTRING_TYPE is/was the necessary first step to attempting
> a better implementation.
> 

I perhaps should describe some modest extensions that improve
on the storage of I18N in headers.

RPM has something called "arbitrary tags" that are essentially an associative array.
The tag name string is digested with SHA1 and the least significant 30bits of the digest
have 0x4000000 (i.e. the 2 most significant bits are 01......), so there are potentially
1G of tagno's in the arbitrary tag space that can be used as an associative array.

E.g. any tag name string can be used as an arbitrary tag like
	Foo:
can be added to package headers by adding to a macro in configuration, and
just adding to *.spec files.

One header tag storage improvement would be to permit tag names like (literally)
	Description(en_US.utf8)
which the *.spec parser can easily generate and implicitly predefine tags of that form
(instead of the rather clunky %_arbitrary_tags macro configuration).

The retrieval of Summary/Group/Description would have to sequentially try
	Description($LANG)
and then (if that tag doesn't exist)
	Description
exactly mimic'ing existing behavior, where the locale is stored in RPMTAG_HEADERI18NTABLE
and a sequential comparison is undertaken before using the C locale.

(aside)
There are other compatibility issues with specspo (and a lookaside cache) that most
distros are using most of this century that can be retrofitted as necessary.

I personally believe that automatic translation through yandex.com, storing the returned
string in a local cache database, with provisions to prime the lookaside cache by
installing a package, or by doing a git checkout, or by using the embedded sqlite,
or mongo, or ... are also needed for "building" and "translation" processes to
become indpendent. 

The current means of distributing all possible locales directly in header metadata
simply does not scale.

When was the last time a distro rebuilt a package to correct a spelling error typo in, say,
the Swahili translation?

Getting rid of RPM_I18NSTRING_TYPE is (imho) a necessary first step in attempting
a better implementation.

YMMV.

73 de Jeff