An EPEL package SPRM shouldn't have the same name as a RHEL package for the same major version and currently a SRPM name must match the Fedora package repo names. This requires creating additional repos which is more work and often a duplication of effort often to support only one branch. It's also prevented package maintainers from publishing some packages, for example, python34 packages for EPEL 7.
I'd like to request we add a capability where a registered virtual/sub/child package repo can used as the SRPM name, so the package source can be stored within the parent repo.
Example:
Package repo: python-dns virtual/sub/child package repo: python3-dns SRPM basename for most python2-dns and python3-dns packages: python-dns SRPM basename for python34-dns.el7: python3-dns All package source stored in branches of python-dns repo
The name should be registered so arbitrary srpm names can't be used.
I'm not sure where all the limitations are. Currently, the first block is encountered by fedpkg build: BuildError: package python3-dns not in list for tag epel7-testing-candidate
I think this would break a bunch of tooling which expects a package to have specific branches and specific src.rpm names based on those. I also think it would casue a lot of confusion because some packages might want this and others might want seperate repos. For example, you may want a different/newer version of python3-dns in epel7 than the version RHEL so it needs to be a new repo.
You could also bring this up to releng and see what they think, but I am not in favor.
So the question would be what we need to support it. It seems many things are based on an assumption the names match, but that's that a particularly good practice. The main thing is many packages do not get into EPEL for this reason. This is particularly obvious when you look at the number of python34 packages in epel7.
As far as confusion, I think what we have today is very confusing. python-dns provides python2-dns and python3-dns packages for Fedora, but python3-dns provides python34 packages for EPEL 7.
Note that there's not much additional bureaucracy with creating, say, a python34-foo repo when python-foo already exists in the distro. It doesn't need a package review or anything like that.
There's going to be confusion either way. There has always been a disconnect between source and binary package names. At least currently there's no disconnect between source package name and the name of the git repository. I think breaking that would be rather terrible, especially since there's no metadata which would provide that mapping.
It would be so much nicer, I think, if we didn't have the restriction on srpm name overlap with RHEL. Why not work on changing that instead of breaking existing Fedora practice?
First I've heard no package review is required. What is the process then?
Tried that already https://pagure.io/epel/issue/34
https://fedoraproject.org/wiki/Packaging:ReviewGuidelines
" The package is being created so that multiple versions of the same package can coexist in the distribution. The package MUST be properly named according to the naming guidelines and MUST NOT conflict with all other versions of the same package. If these requirements are not met, an exemption is required as above."
I'm going to close this now as I don't think there's anything we can do.
I guess your next stop would be the koji devel list or upstream issue tracker to see if they can see a way to avoid the src.rpm / mergerepos issue.
Metadata Update from @kevin: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.