#5272 automatic check for EPEL packages
Closed: Fixed None Opened 9 years ago by mmaslano.

Could you please validate with some automatic script, which packages are already in RHEL and do not create them in EPEL?
It would improve users experience and issues like #5271 wouldn't happen.


That would be lovely, but 2 issues:

a) EPEL sig is still trying to come up with an exact overlapping policy. We know that it will say not to overlap with os or optional, but as to which additional channels on top of that we aren't sure.

b) It's not at all easy to create such a script as this, as new channels are added all the time, packages are added to channels, ability to see whats in all the channels is not there.

Now, it could be that we could just make something now that handles os and optional and add on to it later.
Contributions welcome for such a script. ;)

I strongly agree this would be nice to have and even if it just tested what was in the repositories on a frequent basis and raised flags about conflicts quickly it would be a big help.

So problem 1 is defining the channels that conflicts aren't allowed with. I have opinions about this but the EPEL community just needs to decide what it is. After that it is pretty easy to check from a machine that has access to the defined channels using a bit of repoquery magic. Or a database of protected packages can be generated there to use elsewhere for testing new or existing packages against.

From last discussion with EPEL is more possible that there will be EPEL and EPEL.fast. I guess there might appear same packages in different versions, so my request wouldn't make sense.

Ad contribution, I don't do python.

We are close to having this in place now. More news soon.

This is now all done as pkgdb uses that json file to tell if something is already in RHEL.

Metadata Update from @mmaslano:
- Issue tagged with: easyfix

4 years ago

Login to comment on this ticket.

Metadata