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

[Jeff Johnson]

On Apr 24, 2016, at 6:29 AM, Jan Rękorajski wrote:

> On Mon, 21 Mar 2016, Jeff Johnson wrote:
> 
>> There is a 3rd snapshot release of rpm-5.4.16 now available at
>> 
>> 	http://rpm5.org/files/rpm/rpm-5.4/SNAPSHOT//rpm-5.4.16-0.20160321.src.rpm
>> 
>> This addresses the following issues:
>>    1) mongoc.h needed #include <stdarg.h> to rebuild with PLD configuration
>>    2) build with or without in "system.h"
>>        #define SUPPORT_I18NSTRING_TYPE 1
>> 
>> The tarball has
>>        #undef SUPPORT_I18NSTRING
>> which will display the Summary/Description/Group tags ifrom the header n the C locale aways,
>> and otherwise eliminates the RPM_I18NSTRING_TYPE interface.
> 
> Digging this one up.
> 
> Why are you so set on eliminating RPM_I18NSTRING_TYPE? I don't see any
> explanation anywhere and it will kill a lot of work we put in
> translating spec Summary/Descriptions.
> 

Short answer:
	Patch the define and be happy. Everything "works" as before, none of your "work"
	in *.spec files needs to be changed or is lost.

Longer answer:

I'm interested in removing (by abandoning) a problematic (sometimes RPM_I18NSTRING_TYPE
is a string, sometimes its an array, dependent on context) data type in RPM headers.

There are deeper/harder issues with specifying an encoding for RPM_I18NSTRING_TYPE in a spec file
as well. Already there are some deep hacks in RPM to translate what is usually (PLD is the only distro
I know of that specifies encoding explicitly) implicitly dependent on a LANG/LC_ALL envvar.

The processes of "building" and "translating" are rather different as well. Most distros (unlike PLD)
have some awkward "string freezes" and "string merges" as part of their release cycle that synchronize
the steps needed to hand data to translation teams, and to put translated strings into packages. I
am interested in making these processes more independent of each other, with an alternative
means of distribution and associating Group/Summary/Description with packages. That includes
handling RPMTAG_FILELANGS differently as well.

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.

73 de Jeff

> Jan Rękorajski                    | PLD/Linux
> SysAdm | baggins<at>pld-linux.org | http://www.pld-linux.org/
> _______________________________________________
> pld-devel-en mailing list
> pld-devel-en at lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en