On Fri, Dec 21, 2007, Jeff Johnson wrote:

> OpenPKG and rpm-5.0 are diverging over how arbitrary
> %track gets configured and used.
>
> E.g. vcheck is (usually) present in %{_rpmhome} now, so
> the unavailable check is perhaps unnecessary.

Yes and no. As OpenPKG is fully self-contained. vcheck(1) is written
in Perl, but requires a bunch of Perl addon modules like LWP which
are *not* shipped with Perl by default. Hence OpenPKG's bootstrap
package (where "rpm" is contained) will still require the OpenPKG
"vcheck" package in order to get the necessary dependency packages like
"perl-www", etc.

> The invocation in macros.in has no -v option too.

Yes, that's just because for OpenPKG we really have to be able to know
both what is new and what is still up-to-date by parsing the vcheck
output. But it's fine that stock RPM 5 doesn't use option -v on vcheck:
that's the best default there.

> And there is no || : to mask the returned exit code.

Hmmm... I actually can no longer remember why we are masking the return
code. Perhaps because the only results which we are interested in is the
*output* of the script. But I don't know any longer.

> [...]
> What is realloy needed (imho) is to get vcheck wired into
> --specsrpm and into a BuildRequires: vcheck(...) probe
> (but that's just my teste, -bt is just different).

What would "vcheck(...)" mean respectively what would "..." be in
"vcheck(...)"? I would have expected just "vcheck" there. But OTOH, why
a BuildRequires? Wouldn't this mean that even if I just do a "--rebuild"
on a SRPM I would have "vcheck" to be installed? This certainly should
be not the case. It really should be just required when one does "-bt".
Or is *THIS* what the "vcheck(...)" actually means here, i.e., a
dependency which is only *checked* when %track and vcheck is run?

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