Re: [EPEL] #34: EPEL SRPM naming clarification

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



#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 kevin):

 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'.

-- 
Ticket URL: <https://fedorahosted.org/epel/ticket/34#comment:4>
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




[Index of Archives]     [Fedora Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Announce]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Linux Apps]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux