RPM Community Forums

Mailing List Message of <rpm-devel>

Re: Arbitrary tag names in rpm headers

From: Jeff Johnson <n3npq@mac.com>
Date: Thu 29 Nov 2007 - 15:46:10 CET
Message-Id: <669E8EC5-6E1E-4918-8E84-A7BF08455E1A@mac.com>

On Nov 29, 2007, at 5:13 AM, Klaus Kaempf wrote:

> * Jeff Johnson <n3npq@mac.com> [Nov 27. 2007 15:28]:
>> This thread
>>
>> https://www.redhat.com/archives/fedora-devel-list/2007-November/ 
>> msg02178.html
>> (which is deranged and silly) reminds me of the parallel case  
>> sensitivity
>> issue
>> with rpm tag names.
>>
>> Originally, rpm tag names were case sensitive, just like any unix  
>> input
>> typically is.
>>
>> But SuSE decided (likely because of the German language) that
>> their version of rpm would capitalize the first letter of all tag  
>> names.
>
> Sadly, no of the current engineers at SuSE can remember the reason  
> for this
> so I'd say we're free to fix (or accept) this.
>

Hehe, the reason is cultural, not engineering.

> [...]
>>
>> So I ask:
>>
>>      Is "Arbitrary" an adequate canonical representation for an  
>> otherwise
>>      case insensitive input string used in a spec file such as
>>          Arbitrary: whatever you want
>>
>> or should rpm interpret the following as different tags
>> 	arbitrary:
>> 	ARBITRARY:
>
> Since humans are involved in writing .spec files, please keep tags
> case-_in_sensitive.
>
> (Be generous in what you accept, be strict in what you generate)
>

OK.

What I'm not hearing is perhaps more interesting, and will not be  
present in the
initial implementation:

1) Encoding is ASCII.
2) Arbitrary tags will be parseable according to existing implicit  
(because no grammar exists)
parseSpec rules.

Specifically, that excludes representations like
     "This is an arbitary tag including White  
Space"(with,arbitrary,attributes,nb_NO.ISO-8859-1): containing  
arbitrary non-string data.

SHA-1 certainly does not care what it is fed.

73 de Jeff
Received on Thu Nov 29 15:46:43 2007
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.