On Dec 27, 2007, at 9:38 AM, Ralf S. Engelschall wrote:

> 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.
>

The digest(...) (and other probe-dependencies) are quite general,
can be added to any package, source/binary, as you see fit.

The "I Get It!"
     BuildRequires: digest(/path/to/file) = 1234567812345678
is just to illustrate an obvious usage case, verifying downloaded
contents.

There are of course many other interesting usage cases for uniqification
through crypto hashes for identification, see RFC 4122 and the OSSP
uuid library ;-)

> 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?
>

I'm all about _EASY_ on 12/27/2007 ;-)

The reason for the rather more conceptually convoluted "build(...)"
name space is to provide a forward looking connection point when
one actually wishes rpmlib dependency logical assertions attached. There
are arbitrary tags and types, but there is no such thing as arbitrary
semantics.

(aside) There's another implementation for attaching build dependencies
to binary packages that is more natural and consistent with RPM design
using a header tag extension to lookup RPMTAG_SOURCEPKGID, using
a store-and-forward look-aside cache for srpm headers, that has far
better data normalization properties, and is less intrusive and  
controversial
than adding build dependencies to binary packages. But I digress ...

> 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... ;-)
>

The difficulty with arbitrary tags is that there are no syntax  
templates (yet)
for multiple inter-related tag arrays.

I point to these items in the rpm-5.1 roadmap
     - jbj: arbitrary "%foo -p /bar" scriptlets as pair'ed RPMTAG_ 
{FOO,FOOPROG}.
     - jbj: arbitrary triggers, like scriptlets, but with a condition  
check too.
and I will add an item for an arbitrary dependency parsing syntax  
template
	Foo: N = E:V-R
explicitly to the roadmap today.

But sure, CSV's are known to be as dirt simple as shar archives are:  
WORKSFORME!

73 de Jeff