In order to automate a vcheck invocation through a run-time dependency  
probe,
I'm likely going to need to either propagate a %track section to all  
binary
subpkgs of a build, or generate the %track section from N and EVR  
arguments
in the BuildRequires: dependency.

Currently the %track section is resident only in the *.src.rpm header,  
making
it rather awkward to retrieve the RPMTAG_TRACK section where it is  
needed
in lib/depends.c. Adding the tag to binary headers would permit  
retrieval from
rpmdb headers (and also generalizes rpmbuild -bt nicely, as many %track
sections, not just the section in the current *.src.rpm Header could  
be probed.)

OTOH, its unclear whether there is sufficient benefit to justify  
adding the 100-200
bytes of a %track section to binary headers. Yes, 100-200b is not very  
much, but
I'm sure there will be complaints.

The other approach is to generate the vcheck stanza from the  
{N,EVR,Flags}
triple. A vcheck stanza looks like
     %track
     prog popt = {
         version   = 1.12
         url       = http://rpm5.org/files/%{name}
         regex     = %{name}-(\d+\.\d+)\.tar\.gz
    }

The "version" can be parsed from the dependency EVR tag.

Which leaves the N field to carry both the "url" and "regex" pattern.  
While
that may sound gory and ugly, the typical usage case for automatically
checking that Source0: was latest available would look something like
	Source0: http://rpm5.org/files/%{name}/popt-1.12.tar.gz
	...
	BuildRequires: vcheck(%SOURCEURL0) = %version
and the regex pattern would be generated by a heuristic, replacing
digit strings with \d patterns for matching.

Any opinions before I hack something up?

73 de Jeff