#34: EPEL SRPM naming clarification
-----------------------------+----------------------------
Reporter: aviso | Owner: epel-wranglers
Type: task | Status: new
Priority: major | Milestone:
Component: Policy problem | Version:
Resolution: | Keywords:
-----------------------------+----------------------------
Comment (by aviso):
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.
--
Ticket URL: <https://fedorahosted.org/epel/ticket/34#comment:5>
EPEL <https://fedoraproject.org/wiki/EPEL>
Extra Packages for Enterprise Linux
_______________________________________________
epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
