On Thu, Dec 25, 2014 at 11:41:48AM +0000, Peter Robinson wrote:
>> This morning I wrote a small script that converts yum's
medata into a small json
>> blob that can be used to check if a package is present in RHEL before creating
a
>> branch for it in EPEL, or to restrict building the package on EPEL for certain
>> arch.
>>
>> What is does it basically:
>> - For a list of RHEL version
>> - For a list of directories specific to that RHEL version
>> - Find all the primary.sqlite database
>> - Decompress them if needed
>> - For all the packages listed in the database
>> - get the base package (using the srpm info)
>> - get the epoch, version, release (does nothing w/ it atm)
>> - get the arch - As more arch are found the list grows
>> - Store of the info in a json
>> - Dump the json into a text file
> [...snip...]
>
> There was a question about whether there was any specific Red Hat
> sensitivity. I haven't found any reason against using this kind of
> script. Go for it.
How do we deal with additions of new packages in later RHEL releases?
IIRC we drop them from EPEL or give them a chance to be renamed to compat
packages, but I'll let Kevin or Dennis confirm.
The idea of this script is that we now have a list of the packages in RHEL and
therefore we can check our overlap with EPEL.
EG there's a number of new packages that are in 7.1 beta (and
hence
will be in 7.1 GA) that are now public.
Two things there, iirc for 7.0 there were some packages dropped between the beta
and the release (I remember some packages could be found in the beta repo and
not in the released ones).
And we also ensure that epel does not conflict only on a set of channels, so
depending where these new packages are, we might (or not) have to act in EPEL.
Pierre