On Thu, Dec 27, 2007, Jeff Johnson wrote:

> On Dec 27, 2007, at 7:46 AM, Jeff Johnson wrote:
>> On Dec 27, 2007, at 3:11 AM, Ralf S. Engelschall wrote:
>>
>>> On Wed, Dec 26, 2007, Ralf S. Engelschall wrote:
>>>
>>>> [...]
>>>>    The "BuildRequire" tag is not passed-through
>>>>    to the binary RPM and the RPM database at all!
>>>> [...]
> [...]
>
> The only 2-day implementation hack I can think of is to make
>    BuildRequires: N = E:V-R
> syntactically equivalent to
>    Requires: build(N) = E:V-R

Hmmmm... interesting hack. Ok, understood. Although I'm wondering
what happens if one want to use non-"N = E:V-R" dependencies (e.g.
"BuildRequires: digest(<path>) = <md5>"). AFAIK this would immediately
break as the dependency syntax parser doesn't supported nested
namespaces.

Also I have to say that I searched for a lot simpler hack ;-) I mean,
the value of "BuildRequires" tags which have to be carried forward
actually do not *HAVE* to be available in any *parsed* format from the
binary RPMs or from the RPMDB. It is really just required that the value
is carried forward -- as a plain string would be just fine, too. The
"BuildRequires" value not even has to be parsed (again) later or even
evaluated/checked. It really has to be just simply carried forward in
order to allow RPM frontends to discover the dependencies which were in
place during build-time to correctly trigger rebuilds, etc.

So, the minimum implementation actually would be if we (under
build-time) just _ASSEMBLE_ together (e.g. comma-concatenation) and
_COPY_ the unparsed values on the effective (think about evaluated "%if"
here) "BuildRequires" tags into a single arbitrary tag. This tag is then
stored into the binary RPM and later into the RPMDB. That's it.

Hopefully *THIS* a lot easier to accomplish... what do you think?

PS: With RPM Lua one cannot hack in this feature, as one cannot get the
    effective BuildRequires from the table of all macros. Else I would
    have already generated on-the-fly the arbitrary tag from this
    information... ;-)

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