#34 EPEL SRPM naming clarification
Opened 4 years ago by aviso. Modified 5 months ago

I'm looking for some clarification on the naming requirements for SRPMs. Can an EPEL SRPM have the same name as an SRPM in RHEL?

I asked the question on EPEL-devel [1], but am looking for an official answer. Perhaps the question needs to be addressed at an EPSCO meeting.

[1] https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/7NJAINE6WXQFTTVA3FCQYTX6QXTSOGQ6/


Sure, we can talk about it, but my answer is the same as I gave in the thread.
limited arch packages are allowed to be the same name, everything else is not.

(If I had to do it over I wouldn't have allowed the limited arch thing, but oh well).

This is a +1 to Kevin on both what was said in the thread and that I would not allow the limited arch naming scheme either.

To be clear we are talking about SRPM names. We have several that conflict and as far as I know no one is doing anything about it and it hasn't caused issues.

In the thread, your comment said source packages with the same name would cause issues in Koji. This would only be an issue if A.) RHEL or CentOS used Fedora's build system, or B.) The SRPMs created packages with names that conflicted with RHEL or CentOS binary package names (already against the guidelines)

Unless I am missing something, and please point me to documentation if that is the case, the only thing we are protecting against is a case where an end user has both the OS and EPEL source repos enabled and installs a SRPM by name. I would say that use case isn't enough to justify separating the packages in git.

Frankly I don't care what the SRPM is called. The issue is the build system assumes the SRPM name, the Fedora package name, and the git repo name are the same. This is what prevents having a common git repo and spec. If you have a better solution, I'd be interested to hear it.

Replying to [comment:3 aviso]:

To be clear we are talking about SRPM names. We have several that conflict and as far as I know no one is doing anything about it and it hasn't caused issues.

Well, we have measures in place to prevent branching packages with the same name they have in rhel. Some of the ones you are seeing may be limited arch packages. Otherwise, please let us know what those packages are and we can remove them.

In the thread, your comment said source packages with the same name would cause issues in Koji. This would only be an issue if A.) RHEL or CentOS used Fedora's build system, or B.) The SRPMs created packages with names that conflicted with RHEL or CentOS binary package names (already against the guidelines)

No, it will/can cause problems with EPEL packages building. Limited arch packages avoid this by being very close to the rhel version. If they were not there could well be build problems for epel packages.

Unless I am missing something, and please point me to documentation if that is the case, the only thing we are protecting against is a case where an end user has both the OS and EPEL source repos enabled and installs a SRPM by name. I would say that use case isn't enough to justify separating the packages in git.

No, thats not the case. The case is if we have a package named the same as a rhel package in epel, our buildsystem will use that package over the rhel one. If they are not very close to the same thing, other epel packages that depend on that one will fail to build. Additionally, end users may install that package over the rhel one and then have no support for it. (Which is why limited arch packages have the 0 version pre-pended)

Frankly I don't care what the SRPM is called. The issue is the build system assumes the SRPM name, the Fedora package name, and the git repo name are the same. This is what prevents having a common git repo and spec. If you have a better solution, I'd be interested to hear it.

My solution is: Do not have a package named the same as it is in rhel. If you want to add a EPEL package for python3 support, call the package 'python3-foo' instead of 'python-foo'.

Replying to Kevin:

In the thread, your comment said source packages with the same name would cause issues in Koji. This would only be an issue if A.) RHEL or CentOS used Fedora's build system, or B.) The SRPMs created packages with names that conflicted with RHEL or CentOS binary package names (already against the guidelines)

No, it will/can cause problems with EPEL packages building. Limited arch packages avoid this by being very close to the rhel version. If they were not there could well be build problems for epel packages.

I haven't found anything to back up what you're saying. Can you please show some documentation or point to some code that would?

Unless I am missing something, and please point me to documentation if that is the case, the only thing we are protecting against is a case where an end user has both the OS and EPEL source repos enabled and installs a SRPM by name. I would say that use case isn't enough to justify separating the packages in git.

No, thats not the case. The case is if we have a package named the same as a rhel package in epel, our buildsystem will use that package over the rhel one. If they are not very close to the same thing, other epel packages that depend on that one will fail to build. Additionally, end users may install that package over the rhel one and then have no support for it. (Which is why limited arch packages have the 0 version pre-pended)

Again, we are talking about SRPM names, the binary packages provided do not have the same names so there is no way for them to be used instead. If python-foo is required, the build system will not use python34-foo to meet the requirements regardless what the SRPM is named.

Frankly I don't care what the SRPM is called. The issue is the build system assumes the SRPM name, the Fedora package name, and the git repo name are the same. This is what prevents having a common git repo and spec. If you have a better solution, I'd be interested to hear it.

My solution is: Do not have a package named the same as it is in rhel. If you want to add a EPEL package for python3 support, call the package 'python3-foo' instead of 'python-foo'.

That is not a solution, that is the status quo which has resulted in very few python 3.4 packages for EPEL 7. Generally, the technical effort to build for EPEL 7 is much lower than the administrative effort to maintain two packages in Fedora pkgdb. It's also a confusing naming scheme, because the python3-foo binary RPM for Fedora is provided by the python-foo SRPM, and the python3-foo SRPM has nothing to do with it.

Again, the particular use case is the python-foo SRPM would provide the python34-foo binary RPM. The python-foo binary RPM (Python 2) would not be created unless that package didn't exist in RHEL.

If your concern is the build system, then perhaps the issue is in the build system. Frankly, we wouldn't have this problem if SRPM name did not have to match the Fedora pkgdb names or some sort of alias system existed. Then the SRPM name could be set with a macro and everyone would be happy. However, that seems like it would be a much bigger change to implement as it's a matter of code where this is a matter of policy and we have yet to substantiate any issues that would arise.

https://pagure.io/koji/blob/master/f/builder/mergerepos is the code that merges the repos. mergerepos will ensure that for any given package name (name in the srpm) that only the binary rpms from that nvr of the srpm are included. Possibly the code can be tricked with packages having the exact same nvr ( I ahve not tested so not 100%, however it would be too fragile to keep build nvrs in exact lockstep with the RHEL versions. The thing that defines what sub packages get included is the name of the srpm.

Everything is done in dist-git, pkgdb, koji etc for a reason, that being namely auditability and accontability.

Ausil, thanks. That's very useful. It would appear someone at some point made an assumption SRPM names would be a valid unique identifier. I can understand why, but it seems rather arbitrary, which is why, as you said, the system is fragile. If the purpose of that script is to merge binary repos, why would you need to deconflict if there was no conflict in the provides? It seems like a step is missing.

Everything is done in dist-git, pkgdb, koji etc for a reason, that being namely auditability and accontability.

I have no doubt, but the whole business we're in, computers, serves the purpose of reducing human work. If humans have to do anything, there is room for improvement.

Not only do we have too much human work required, it's administrative rather than technical, the impact is high for the end user, and it's only getting worse as the demand for Python 3 increases.

So, what would we recommend, a modification to the merge script to filter by provides first, a system to alias package names in pkgdb, or something else?

This issue looks like it has been resolved.
Does anyone mind if I close it?

Metadata Update from @tdawson:
- Issue close_status updated to: None

5 months ago

Login to comment on this ticket.

Metadata