On Dec 21, 2007, at 4:32 PM, Ralf S. Engelschall wrote:

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

Sure there's a buttload of flaws with missing dependencies for
additional perl modules relying on an invocation failure
for %{_rpmhome}/vcheck helper. But none of those
missing dependency issues are addressed in yr %{L_vheck}
execution test either.

Truly, I'm not criticizing the OpenPKG use of vhcheck. In fact,
I think that vcheck(1) is the cat's pajamas, and expect the
check for later upstream versions to be a killer feature.
I too wish to sleep at night ;-)

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

I can easily ad -v, just dinna know any better ...

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

The exit code for vcheck invocation through rpmbuild -vt hardly
matters. I just meant to point out different behavior.

>> [...]
>> 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?
>

IMHO, a run-time boolean valued probe function, returning TRUE/FALSE
if condition is not met (in the case of BuildRequires: vcheck(...)  
the condition
is that no newer sources are available upstream ...) is better  
automation.

Adding as a BuildRequires: does the upstream version check where needed,
during build.

Note: Add BuildRequires(hint): if one does not want the boolean  
valued run-time
dependency probe to not be a build failure condition. Perhaps  
obscure ...

Nothing wrong with yr "rpmbuild -bt ..." implementation whatsoever, I  
just believe
in better automation too. AFAICT, the desire (and goal for rpmbuild)  
is to instrument
build success verification as early as possible. This is build  
process control, occaisonal
false failures can be tolerated if the overall process control goal  
makes sense.

So should I wire -v to "rpmIsverbose()" of just add to macros.in.

What I want to see is a common approach, whatever works for OpenPkg,  
works for rpm-5.0 too.

Longer term, I shall likely re-implement vcheck in C under rpmio to  
avoid the buttload of
missing perl dependencies. The functionality is too useful to rpm to  
mess around
with perl Artistic anarchy imho. I can/will leave behind a macro for  
those who insist on
the gud old stuff external to rpm (and rpmio) ...

Make sense?

73 de Jeff