bugs: smart on fc5

[Jeff Johnson]

On Apr 25, 2006, at 8:02 AM, Dag Wieers wrote:

> On Wed, 12 Apr 2006, Jeff Johnson wrote:
>
>> On Apr 12, 2006, at 10:27 AM, Darko Veberic wrote:
>>
>> The problem is that rpm data (like description) does not supply a  
>> clear and
>> unambiguous encoding.
>>
>> Without a known encoding, a transformation is very tricky, as  
>> guessing the
>> encoding from a string is not simple.
>>
>> Unknown encodings for metadata strings is a fundamental design  
>> problem in rpm,
>> not smart, and needs to be
>> fixed within rpm. The work to force utf-8 encodings onto all rpm  
>> metadata is
>> well underway, should be in rpm-4.4.7
>> final when released.
>
> Hey Jeff,
>
> Are there any recommendations for packagers to work around this for  
> older
> (all existing) RPM releases ? Dries made some effort to convert  
> SPEC files
> to UTF8 format more than a year ago, but does that help or is there
> something else we can do to have more consistent metadata end up in  
> the
> package ?
>

Hey Dag!

Running spec files through iconv(1) and converting to utf8 "fixes"  
the problem no matter what,
all versions of rpm. There still may be a few silliy issues with  
encodings within
file paths that are not mentioned in spec files, but there aren't  
more than a few
packages with encoding issues on file paths afaik.

Meanwhile, recent (like since 4.4.4) rpm will convert latin1 to utf8  
for changelogs, which
is where the worst of the mess is.

In addition, the same latin1 -> utf8 convert is now wired into --xml  
and --yaml so that
I can see whether the conversion is reliable. That's how I discovered  
only
latin1 so far.

I'll probably attempt a ??? -> utf8 conversion on the spec file  
during build,
failing all builds that do not convert, with a disabler to give  
distros like
mdk and pld time to convert their i18n tags in spec files.

Not hard code, just a boring and tedious issue.

73 de Jeff