From Fedora Project Wiki
m (1 revision(s)) |
m (Fixed template) |
||
| Line 1: | Line 1: | ||
{ | {{Draft}} | ||
= Packaging in EPEL = | = Packaging in EPEL = | ||
| Line 11: | Line 8: | ||
== General exceptions == | == General exceptions == | ||
* Packages in EPEL should never replace packages from the enterprise distribution it was build for | * Packages in EPEL should never replace packages from the enterprise distribution it was build for | ||
* Packages in EPEL should never knowingly cause trouble in packages of the enterprise distribution that the package is build for | * Packages in EPEL should never knowingly cause trouble in packages of the enterprise distribution that the package is build for | ||
* Software that is in some form part of a enterprise distribution version or one of its spins is not allowed in the EPEL release for that product version | * Software that is in some form part of a enterprise distribution version or one of its spins is not allowed in the EPEL release for that product version | ||
* kernel modules are not allowed in EPEL | * kernel modules are not allowed in EPEL | ||
| Line 27: | Line 19: | ||
* RHEL Python packages should manually depend on the proper python version that it was build for. Most old FC-3 python packages should still use this trick. | * RHEL Python packages should manually depend on the proper python version that it was build for. Most old FC-3 python packages should still use this trick. | ||
[[Category:EnterpriseExtras]] | [[Category:EnterpriseExtras]] | ||
Latest revision as of 01:16, 3 June 2008
This page is a draft only
It is still under construction and content may change. Do not rely on the information on this page.
It is still under construction and content may change. Do not rely on the information on this page.
Packaging in EPEL
The packages in EPEL mainly follow the Fedora Packaging Guidelines -- that includes packaging guidelines , the package naming guidelines and the package review guidelines that are designed and maintained by the Packaging Committee .
But there are some exceptions for packages in EPEL, which are listed below.
General exceptions
- Packages in EPEL should never replace packages from the enterprise distribution it was build for
- Packages in EPEL should never knowingly cause trouble in packages of the enterprise distribution that the package is build for
- Software that is in some form part of a enterprise distribution version or one of its spins is not allowed in the EPEL release for that product version
- kernel modules are not allowed in EPEL
Distribution specific exceptions
EL4
- RHEL Python packages should manually depend on the proper python version that it was build for. Most old FC-3 python packages should still use this trick.