On Wed, Dec 26, 2007, Jeff Johnson wrote:

> 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())... :-(
>
> So do you wish to raise the size of the parse buffer to, say, 200K?
> Anything else is going to hard to fit into rpm-5.0 ...

The problem is that a few hundret KB might be still too small. I think
to really be able to put larger amounts into a tag we really would have
to implement the dynamic buffer reallocation. Any type of static buffer
just slightly moves forward the time when it starts breaking...

Nevertheless we should increase from the rather small 10KB to perhaps at
least something like 100KB. This way it obviously is still unusable for
something like my "Environment" approach (where the data exponentially
explodes even under tree pruning), but at least other tag hacks then
work...

                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com