On Dec 26, 2007, at 2:59 PM, Ralf S. Engelschall wrote:

> On Thu, Dec 13, 2007, Jeff Johnson wrote:
>
>> On Dec 13, 2007, at 2:34 PM, Ralf S. Engelschall wrote:
>>
>> [...]
>>> BUT: one question remains which I was not easily able to figure  
>>> out from
>>> the sources: WHAT IS THE SIZE LIMIT OF TAGS IN RPM 5?
>>
>> Hard to say absolutely, but the previously imposed tag data store
>> limit has been changed from 32Mb to 1Gb AFAIK. There are other limits
>> that constrain the "WHAT IS THE SIZE LIMIT OF TAGS IN RPM 5?"
>> such as the total size of the data store, which is (afaik) 2GB  
>> because
>> of the necessity to keep the offset a int32_t, the sign change is  
>> used
>> as a immutable region marker. The additional constraints prevent  
>> giving
>> a precise answer.
>> [...]
>
> I finally poked around in the code a lot deeper and IMHO the precise
> answer is: 10*BUFSIZE which on most platforms mean just 10KB, because
> build/rpmspec.h shows a "char lbuf[10*BUFSIZ];" which internally is
> used for the macro expansion on lines during the .spec file parsing.  
> If
> I'm not completely wrong here, this unfortuntely means we can entirely
> forget putting rather large amounts of data into a tag via RPM Lua  
> macro
> expansions (or generation via Lua print())... :-(
>

Oh you're asking parsing and macro expansions. My answer was wrto binary
tags in headers.

FWIW, your answer is likely specific to the spec file parsing code  
path, not
all code paths, by which macros are expanded.

The eventual fix will be to realloc during macro expansion and remove
the 3 or 4 places that don't use rpmExpand().

The quick fix is just to change 10 to something sufficiently larger.  
The original
limit was 1K, 10*BUFSIZ has been large enough.

There still has to be a better representation for, like an argv array  
of elements
each of which is limited to 10 * BUFSIZ, rather that one
humoungous serial representation pickled with lua.

73 de Jeff