On 06/19/2014 11:38 AM, Patrick J. LoPresti wrote:
> On Thu, Jun 19, 2014 at 6:00 AM, Lamar Owen <[log in to unmask]> wrote:
>> for a particular package, you can grab the updated spec file (using the
>> commit feeds), pull the NEVRA info out of it
> As Nico points out, this is assuming regularity and meaning in the
> NEVRA values that are tenuous at best. Has Red Hat made any commitment
> to provide such regularity and meaning? If not, why would you assume
> them?

I would assume that the src.rpm package name and the NEVRA values from 
which the package file name derives would be consistent between 
themselves (and I don't know of a package for which this is not true, 
but I reserve the right to be wrong).  That is, if you have 
foo.1-2el7.src.rpm you will have a spec that says the name is foo, the 
version is 1, and the release is 2el7.  Architecture is only relevant 
for binary, not source rpms, and epoch is hidden from the filename.  But 
this is basic stuff.  You are getting exactly the same information in a 
de-packaged tree with spec, sources, and patches as you would with the 
packaged src.rpm except for build-generated metadata such as build host 
and build time, and the package signature.  If those build-generated 
values are important to you then this way is a setback; if those values 
aren't meaningful, then you are getting exactly the same information.  
After all, Red Hat doesn't have the EL6 SRPMs tagged by update number 
either; there is just a single directory containing all of the src.rpms 
released for that particular variant.

> Yes, I have been following the CentOS lists. It sounds like a huge 
> pain in the butt and extremely fragile besides. 

It does sound like a learning curve, but it's pretty obvious that 
progress is being made.

> Red Hat could make it trivial and completely robust, with zero effort, 
> simply by tagging the repositories. Why don't they do that, I wonder? 
> - Pat 
I don't wonder.  I have a pretty good idea why they might not do that, 
and it could be simply to make it harder for Red Hat's commercial 
competitors.  This was hashed over back when EL6 was released with all 
the uproar about the way the kernel source was packaged, so I won't go 
over old ground with it.