More consistent markup; remove dupe page for package requests
This commit is contained in:
parent
f618be18b0
commit
c322217b67
12 changed files with 184 additions and 154 deletions
|
|
@ -53,11 +53,11 @@ created
|
|||
|
||||
This will result in an EPEL Next package that is the same as the
|
||||
existing EPEL package, except for the `.next` suffix on the disttag and
|
||||
being built against CentOS Stream 9. Your epel9-next branches can
|
||||
being built against CentOS Stream 9. Your `epel9-next` branches can
|
||||
diverge from the corresponding epel9 branches as needed. If an update
|
||||
for your EPEL package requires a minimum version of a dependency that is
|
||||
only in CentOS Stream so far, you can update in the epel9-next branch
|
||||
first, then merge from epel9-next to epel9 when the dependency is added
|
||||
only in CentOS Stream so far, you can update in the `epel9-next` branch
|
||||
first, then merge from `epel9-next` to `epel9` when the dependency is added
|
||||
to the next RHEL minor release.
|
||||
|
||||
== FAQ
|
||||
|
|
|
|||
|
|
@ -276,14 +276,15 @@ time you install an EPEL package.
|
|||
If you want to find out if a package comes from EPEL, use a query such
|
||||
as this:
|
||||
|
||||
....
|
||||
[,console]
|
||||
----
|
||||
rpm -qp foo-0.1-5.el5.i386.rpm --qf '%{NAME}-%{VERSION}-%{RELEASE} %{VENDOR}\n'
|
||||
foo-0.1-5.el5 Fedora Project
|
||||
rpm -qp foo-0.1-5.el5.i386.rpm --qf '%{NAME}-%{VERSION}-%{RELEASE} %{DISTRIBUTION}\n'
|
||||
foo-0.1-5.el5 Extras Packages for Enterprise Linux
|
||||
rpm -qp foo-0.1-5.el5.i386.rpm --qf '%{NAME}-%{VERSION}-%{RELEASE} %{SIGPGP}\n'
|
||||
foo-0.1-5.el5 883f030500468e3e4e119cc036217521f611025863009f5fe424c6fe4bc81a57f45722e465e71381dda2f6009f7c08e1743794b5b9a5a4cd149081092801a5d935
|
||||
....
|
||||
----
|
||||
|
||||
Or you can install and run the 'keychecker' script to list all packages
|
||||
signed with a particular key as well as which repo they came from.
|
||||
|
|
@ -329,7 +330,7 @@ as Fedora except that you request an EPEL branch such as epel8 or epel9.
|
|||
[[how_do_i_request_a_epel_branch_for_an_existing_fedora_package]]
|
||||
=== How do I request a EPEL branch for an existing Fedora package?
|
||||
|
||||
Look xref:fedora-package-in-epel.adoc[here for the procedure used
|
||||
Look xref:epel-package-request.adoc[here for the procedure used
|
||||
to get a Fedora package in EPEL].
|
||||
|
||||
[[i_maintain_a_package_in_fedora._do_i_have_to_maintain_it_for_epel]]
|
||||
|
|
@ -416,7 +417,7 @@ and is thus eligible for EPEL.
|
|||
[[i_want_to_build_packages_for_epel_but_some_of_my_packages_dependencies_are_not_available_in_epel____or____id_like_to_see_a_fedora_package_in_epel_that_is_not_yet_available_there]]
|
||||
=== I want to build packages for EPEL but some of my packages dependencies are not available in EPEL -- or -- I'd like to see a Fedora package in EPEL that is not yet available there
|
||||
|
||||
See xref:fedora-package-in-epel.adoc[here how to get a Fedora
|
||||
See xref:epel-package-request.adoc[here how to get a Fedora
|
||||
package in EPEL].
|
||||
|
||||
[[rhel_8_has_binaries_in_the_release_but_is_missing_some_corresponding__devel_package._how_do_i_build_a_package_that_needs_that_missing__devel_package]]
|
||||
|
|
@ -427,16 +428,16 @@ should be used together.
|
|||
|
||||
* Short Term: Create an epel package that only has the missing packages.
|
||||
** Be prepared to maintain this package as long as it is needed.
|
||||
** It is recommended that you name it <package>-epel
|
||||
** It is recommended that you name it `<package>-epel`
|
||||
** It is recommended that you add the epel-packagers-sig group as a
|
||||
co-maintainer
|
||||
** It qualifies for an exception to the xref:packaging-guidelines::ReviewGuidelines.adoc[package review process] so you can request the repo with
|
||||
*** fedpkg request-repo --exception <package>-epel
|
||||
*** `fedpkg request-repo --exception <package>-epel`
|
||||
** Once the repo is created, you must retire the rawhide branch to make it clear that this is an EPEL-only package and it shouldn't be branched for future Fedora releases
|
||||
*** fedpkg retire 'EPEL-only package'
|
||||
*** `fedpkg retire 'EPEL-only package'`
|
||||
** If you need help building this, ask for help. We have some examples.
|
||||
** When/If the missing package(s) are added to RHEL CRB, retire your
|
||||
-epel package.
|
||||
`-epel` package.
|
||||
|
||||
* Long Term: Request the package be added to RHEL 8 and 9 CRB
|
||||
repository.
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ lives on in case you do not.
|
|||
|
||||
This role includes maintaining one or more packages through the Fedora
|
||||
Project. These packages are rebuilt in the Fedora Extra Packages for
|
||||
Enterprise Linux (EPEL) repository (link:++https://fedoraproject.org/wiki/EPEL++[]).
|
||||
Enterprise Linux (EPEL) repository (link:++https://docs.fedoraproject.org/en-US/epel/++[]).
|
||||
The list of packages is not specified here, because it may need to
|
||||
fluctuate over time, but a list should be maintained with the group
|
||||
manager/project lead.
|
||||
|
|
|
|||
|
|
@ -8,35 +8,35 @@ include::partial$attributes.adoc[]
|
|||
EPEL packages are maintained by members of the community. These
|
||||
maintainers respond to bug reports, update packages and add new packages
|
||||
to the collection as needed. EPEL packagers are members of the Fedora
|
||||
"packagers" group.
|
||||
`packagers` group.
|
||||
|
||||
[[joining_the_epel_package_maintainers]]
|
||||
== Joining the EPEL package maintainers
|
||||
|
||||
There are several ways you can join the EPEL package maintainer group:
|
||||
|
||||
{empty}1. If you are an existing Fedora package maintainer, you can
|
||||
. If you are an existing Fedora package maintainer, you can
|
||||
maintain EPEL packages by becoming a maintainer or co-maintainer of an
|
||||
existing EPEL package, which you can apply for in pkgdb. You can also
|
||||
xref:epel-faq.adoc#how_do_i_request_a_epel_branch_for_an_existing_fedora_package[request
|
||||
EPEL branches] for your Fedora package and maintain them for EPEL with a
|
||||
Package SCM request.
|
||||
|
||||
{empty}2. If you are not currently in the Fedora packager group, you
|
||||
. If you are not currently in the Fedora packager group, you
|
||||
could join that group by submitting one or more new packages for
|
||||
Fedora/EPEL, and following the normal Fedora sponsorship process. Then,
|
||||
simply
|
||||
xref:epel-faq.adoc#how_do_i_request_a_epel_branch_for_an_existing_fedora_package[request
|
||||
EPEL branches] for your new packages once they are approved.
|
||||
|
||||
{empty}3. If you are not currently in the Fedora packager group and wish
|
||||
. If you are not currently in the Fedora packager group and wish
|
||||
to help co-maintain one or more packages in EPEL, you can try and find
|
||||
an existing package and maintainer of that package who wishes to mentor
|
||||
you. You can then follow the
|
||||
xref:package-maintainers::How_to_Get_Sponsored_into_the_Packager_Group.adoc#become_a_co_maintainer["Become
|
||||
a co-maintainer" path to sponsorship].
|
||||
|
||||
{empty}4. If you are an existing EPEL/Fedora maintainer and wish to
|
||||
. If you are an existing EPEL/Fedora maintainer and wish to
|
||||
maintain a package in EPEL that someone else maintains in Fedora, file a
|
||||
bug asking them if they would like to maintain it in EPEL, if no
|
||||
response in a week or if the Fedora maintainer has no interest in EPEL,
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ but those are out of scope for this guide.
|
|||
== Determine the component
|
||||
|
||||
EPEL package requests are tracked in bugzilla.
|
||||
The *source package* name is used as the bugzilla component field.
|
||||
The *source package* name is used as the bugzilla `Component` field.
|
||||
This may or may not be the same as the package name you are looking for.
|
||||
If you are not sure what the source package name is,
|
||||
search for your desired package in the
|
||||
|
|
@ -29,6 +29,7 @@ link:++https://packages.fedoraproject.org/++[Fedora Packages web app].
|
|||
Once you locate the desired package in this app,
|
||||
the URL will have the following structure:
|
||||
|
||||
[,console]
|
||||
----
|
||||
https://packages.fedoraproject.org/pkgs/<source_package>/<package>/
|
||||
----
|
||||
|
|
@ -42,8 +43,9 @@ Use the source package name for the component in the rest of this guide.
|
|||
|
||||
Before opening a new bug report,
|
||||
check the existing ones to see if the package has already been requested.
|
||||
Use the following URL (replacing "<component>" with your component) to view existing open bugs.
|
||||
Use the following URL (replacing `<component>` with your component) to view existing open bugs.
|
||||
|
||||
[,console]
|
||||
----
|
||||
https://bugz.fedoraproject.org/<component>
|
||||
----
|
||||
|
|
@ -54,28 +56,28 @@ then open a new bug at link:++https://bugzilla.redhat.com/enter_bug.cgi++[].
|
|||
[NOTE]
|
||||
.Bugzilla fields for an EPEL request
|
||||
====
|
||||
* Classification: Fedora
|
||||
* Product: Fedora EPEL
|
||||
* Component: <component> (if the component is not found, skip to the next note)
|
||||
* Version: epel9 (or epel8, etc.)
|
||||
* Classification: `Fedora`
|
||||
* Product: `Fedora EPEL`
|
||||
* Component: `<component>` (if the component is not found, skip to the next note)
|
||||
* Version: `epel9` (or `epel8`, etc.)
|
||||
* Summary: Please branch and build <package> in epel9 (or epel8, etc.)
|
||||
====
|
||||
|
||||
If this package has never been in EPEL before,
|
||||
the component will not exist in the "Fedora EPEL" product.
|
||||
You can still request the package by using the "Fedora" product.
|
||||
the component will not exist in the `Fedora EPEL` Product.
|
||||
You can still request the package by using the `Fedora` Product.
|
||||
|
||||
[NOTE]
|
||||
.Bugzilla fields for an EPEL request (alternative)
|
||||
====
|
||||
* Classification: Fedora
|
||||
* Product: Fedora
|
||||
* Component: <component>
|
||||
* Version: rawhide
|
||||
* Classification: `Fedora`
|
||||
* Product: `Fedora`
|
||||
* Component: `<component>`
|
||||
* Version: `rawhide`
|
||||
* Summary: Please branch and build <package> in epel9 (or epel8, etc.)
|
||||
====
|
||||
|
||||
If the component isn't found in either the "Fedora EPEL" or "Fedora" products,
|
||||
If the component isn't found in either the `Fedora EPEL` or `Fedora` Products,
|
||||
then it probably doesn't exist in Fedora and needs to be added there first.
|
||||
|
||||
At this point, things change depending on your ability or willingness to help.
|
||||
|
|
@ -83,49 +85,60 @@ At this point, things change depending on your ability or willingness to help.
|
|||
[[end_users]]
|
||||
=== Consumers/end users
|
||||
|
||||
Clear out Description and put
|
||||
Clear out `Description` and put in:
|
||||
|
||||
....
|
||||
[,console]
|
||||
----
|
||||
Please branch and build <package> in epel9.
|
||||
....
|
||||
----
|
||||
|
||||
If there is no response after a week, add the following comment in the bug.
|
||||
If there is no response after a week, add the following comment in the bug:
|
||||
|
||||
....
|
||||
[,console]
|
||||
----
|
||||
Will you be able to branch and build <package> in epel9?
|
||||
....
|
||||
----
|
||||
|
||||
If there is no action on the bug after two more weeks, send an email to link:++https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org/++[epel-devel] asking if there are any packagers
|
||||
who would like to package and maintain your package on epel. Be sure to include the Bugzilla URL in your email.
|
||||
who would like to package and maintain your package in EPEL. Be sure to include the Bugzilla URL in your email.
|
||||
|
||||
[[fedora_packagers]]
|
||||
=== Fedora/EPEL packagers
|
||||
|
||||
Clear out Description and put
|
||||
Clear out Description and put in:
|
||||
|
||||
....
|
||||
[,console]
|
||||
----
|
||||
Please branch and build <package> in epel9.
|
||||
|
||||
If you do not wish to maintain <package> in epel9,
|
||||
or do not think you will be able to do this in a timely manner,
|
||||
I would be happy to be a co-maintainer of the package (FAS <your FAS Id>);
|
||||
please add me through https://src.fedoraproject.org/rpms/<package>/adduser
|
||||
....
|
||||
----
|
||||
|
||||
If there is no response after a week, add the following comment in the bug.
|
||||
If there is no response after a week, add the following comment in the bug:
|
||||
|
||||
....
|
||||
[,console]
|
||||
----
|
||||
Will you be able to branch and build <package> in epel9?
|
||||
I would be happy to be a co-maintainer if you do not wish
|
||||
to build it on epel9 (FAS: <your FAS Id>).
|
||||
....
|
||||
----
|
||||
|
||||
If there is no action on the bug after two more weeks, follow the xref:epel-package-request.adoc#stalled_epel_requests[stalled EPEL request steps], and open a ticket with link:++https://pagure.io/releng/issues/++[releng]
|
||||
If there is no action on the bug after two more weeks, follow the xref:epel-package-request.adoc#stalled_epel_requests[stalled EPEL request steps], and open a ticket with link:++https://pagure.io/releng/issues/++[releng]:
|
||||
|
||||
* Ticket Title:
|
||||
** Stalled EPEL package: <package>
|
||||
+
|
||||
[,console]
|
||||
----
|
||||
Stalled EPEL package: <package>
|
||||
----
|
||||
|
||||
* Ticket Body:
|
||||
....
|
||||
+
|
||||
[,console]
|
||||
----
|
||||
* Describe the issue
|
||||
<package> is a stalled EPEL package.
|
||||
Per the EPEL stalled package policy - https://docs.fedoraproject.org/en-US/epel/epel-package-request/#stalled_epel_requests - I have contacted the maintainer, twice, and waited the appropriate amount of time.
|
||||
|
|
@ -133,16 +146,17 @@ Per the EPEL stalled package policy - https://docs.fedoraproject.org/en-US/epel/
|
|||
I am requesting <my_FAS_id> be given commit permissions so that I might branch and build this package in epel9.
|
||||
|
||||
<Fill out the other sections as you see fit>
|
||||
....
|
||||
----
|
||||
|
||||
After you have been given commit permissions, you can then branch, build, and maintain the package in epel.
|
||||
|
||||
[[epel_packagers_sig_members]]
|
||||
=== EPEL packagers SIG members
|
||||
|
||||
Clear out Description and put
|
||||
Clear out `Description` and put in:
|
||||
|
||||
....
|
||||
[,console]
|
||||
----
|
||||
Please branch and build <package> in epel9.
|
||||
|
||||
If you do not wish to maintain <package> in epel9,
|
||||
|
|
@ -157,22 +171,30 @@ I would also be happy to be a co-maintainer (FAS: <my_FAS_id>).
|
|||
|
||||
(optionally, if there's not a separate Bugzilla assignee for EPEL)
|
||||
I can be the primary contact for EPEL (FAS: <my_FAS_id>).
|
||||
....
|
||||
----
|
||||
|
||||
If there is no response after a week, add the following comment in the bug.
|
||||
|
||||
....
|
||||
[,console]
|
||||
----
|
||||
Will you be able to branch and build <package> in epel9?
|
||||
The EPEL Packagers SIG would be happy to be a co-maintainer
|
||||
if you do not wish to build it on epel9.
|
||||
....
|
||||
----
|
||||
|
||||
If there is no action on the bug after two more weeks, follow the xref:epel-package-request.adoc#stalled_epel_requests[stalled EPEL request steps], and open a ticket with link:++https://pagure.io/releng/issues/++[releng]
|
||||
|
||||
* Ticket Title:
|
||||
** Stalled EPEL package: <package>
|
||||
+
|
||||
[,console]
|
||||
----
|
||||
Stalled EPEL package: <package>
|
||||
----
|
||||
|
||||
* Ticket Body:
|
||||
....
|
||||
+
|
||||
[,console]
|
||||
----
|
||||
* Describe the issue
|
||||
<package> is a stalled EPEL package.
|
||||
Per the EPEL stalled package policy - https://docs.fedoraproject.org/en-US/epel/epel-package-request/#stalled_epel_requests - I have contacted the maintainer, twice, and waited the appropriate amount of time.
|
||||
|
|
@ -180,9 +202,9 @@ Per the EPEL stalled package policy - https://docs.fedoraproject.org/en-US/epel/
|
|||
I am a member of the epel-packagers-sig and I am requesting epel-packagers-sig be given commit permissions so that I, or a member of the SIG, might branch and build this package in epel9. Please also add my account: <my_FAS_id>.
|
||||
|
||||
<Fill out the other sections as you see fit>
|
||||
....
|
||||
----
|
||||
|
||||
After the epel-packagers-sig has been given commit permissions, you can then branch, build, and maintain the package in epel.
|
||||
After the `epel-packagers-sig` has been given commit permissions, you can then branch, build, and maintain the package in EPEL.
|
||||
|
||||
[[stalled_epel_requests]]
|
||||
== Stalled EPEL requests
|
||||
|
|
|
|||
|
|
@ -11,42 +11,48 @@ These examples are for the xref:epel-policy-missing-sub-packages.adoc#short_ter
|
|||
|
||||
This is an example workflow.
|
||||
|
||||
* *fedpkg request-repo --exception <package>-epel*
|
||||
** fedpkg request-repo --exception pycairo-epel
|
||||
* *fedpkg request-branch --repo <package>-epel epel<version>*
|
||||
** fedpkg request-branch --repo pycairo-epel epel9
|
||||
** Note: request-repo and request-branch can be done at the same time as long as request-repo is done first
|
||||
* Wait until you get an email saying the request is done
|
||||
* *fedpkg clone <package>-epel ; cd <package>-epel*
|
||||
** fedpkg clone pycairo-epel ; cd pycairo-epel
|
||||
* *fedpkg retire "For epel only, not Fedora"*
|
||||
* *fedpkg switch-branch epel<version>*
|
||||
** fedpkg switch-branch epel9
|
||||
* Download the source rpm corresponding to the latest released RHEL build
|
||||
* *fedpkg import <full patch to source rpm>*
|
||||
** fedpkg import /tmp/pycairo-1.20.0-4.el9.src.rpm
|
||||
* *fedpkg commit -m "import from CentOS Stream srpm"*
|
||||
* *git mv <package>.spec <package>-epel.spec*
|
||||
** git mv pycairo.spec pycairo-epel.spec
|
||||
* *fedpkg commit -m "rename spec file"*
|
||||
* Edit the spec file so it builds, but only produces the missing binaries
|
||||
* Test build and test install your rpm, which ever way you like to do that
|
||||
* *fedpkg commit -m "Convert RHEL<version> <package> to <package>-epel with just <package>-devel subpackage"*
|
||||
** fedpkg commit -m "Convert RHEL9 pycairo to pycairo-epel with just python3-cairo-devel subpackage"
|
||||
* *fedpkg push*
|
||||
* *fedpkg build*
|
||||
* *fedpkg update*
|
||||
. `fedpkg request-repo --exception <package>-epel`
|
||||
* For example: fedpkg request-repo --exception pycairo-epel
|
||||
. `fedpkg request-branch --repo <package>-epel epel<version>`
|
||||
* For example: `fedpkg request-branch --repo pycairo-epel epel9`
|
||||
+
|
||||
[NOTE]
|
||||
====
|
||||
`request-repo` and `request-branch` can be done at the same time as long as `request-repo` is done first.
|
||||
====
|
||||
. Wait until you get an email saying the request is done
|
||||
. `fedpkg clone <package>-epel ; cd <package>-epel`
|
||||
* For example: `fedpkg clone pycairo-epel ; cd pycairo-epel`
|
||||
. `fedpkg retire "For epel only, not Fedora"`
|
||||
. `fedpkg switch-branch epel<version>`
|
||||
* For example: `fedpkg switch-branch epel9`
|
||||
. Download the source rpm corresponding to the latest released RHEL build
|
||||
. `fedpkg import <full patch to source rpm>`
|
||||
* For example: `fedpkg import /tmp/pycairo-1.20.0-4.el9.src.rpm`
|
||||
. `fedpkg commit -m "import from CentOS Stream srpm"`
|
||||
. `git mv <package>.spec <package>-epel.spec`
|
||||
* For example: `git mv pycairo.spec pycairo-epel.spec`
|
||||
. `fedpkg commit -m "rename spec file"`
|
||||
. Edit the spec file so it builds, but only produces the missing binaries
|
||||
. Test build and test install your rpm, which ever way you like to do that
|
||||
. `fedpkg commit -m "Convert RHEL<version> <package> to <package>-epel with just <package>-devel subpackage"`
|
||||
* For example: `fedpkg commit -m "Convert RHEL9 pycairo to pycairo-epel with just python3-cairo-devel subpackage"`
|
||||
. `fedpkg push`
|
||||
. `fedpkg build`
|
||||
. `fedpkg update`
|
||||
|
||||
=== Missing-but-built spec examples
|
||||
|
||||
These examples should help you convert your RHEL spec file to a -epel spec file.
|
||||
These examples should help you convert your RHEL spec file to a `-epel` spec file.
|
||||
|
||||
==== Header/top of spec
|
||||
|
||||
* State where the original spec came from, and where to look to make sure it is in sync.
|
||||
* A variable for the original name of the package. It doesn't have to be rhel_name, but keep it consistent.
|
||||
** Do a global replacement of %\{name} to %\{rhel_name} in your spec file.
|
||||
* Turn off debugsource
|
||||
* State where the original spec came from, and where to look to make sure it is
|
||||
in sync.
|
||||
* A variable for the original name of the package. It doesn't have to be
|
||||
`rhel_name`, but keep it consistent.
|
||||
** Do a global replacement of `%\{name} to %\{rhel_name}` in your spec file.
|
||||
* Turn off debugsource.
|
||||
|
||||
....
|
||||
# This spec file is derived from the RHEL9 pycairo spec file. They should be kept
|
||||
|
|
@ -59,7 +65,8 @@ These examples should help you convert your RHEL spec file to a -epel spec file.
|
|||
|
||||
==== %prep
|
||||
|
||||
Add "-n %\{rhel_name}-%\{version}" to your setup. So the build doesn't think the source is in <package>-epel-version.
|
||||
Add `-n %\{rhel_name}-%\{version}` to your setup.
|
||||
So the build doesn't think the source is in `<package>-epel-version`.
|
||||
|
||||
....
|
||||
%prep
|
||||
|
|
@ -69,7 +76,7 @@ Add "-n %\{rhel_name}-%\{version}" to your setup. So the build doesn't think th
|
|||
|
||||
==== %package %description and %files
|
||||
|
||||
You need to add "-n %\{rhel_name}-" to each of these.
|
||||
You need to add `-n %\{rhel_name}-` to each of these.
|
||||
|
||||
....
|
||||
%package -n %{rhel_name}-devel
|
||||
|
|
@ -79,19 +86,24 @@ You need to add "-n %\{rhel_name}-" to each of these.
|
|||
|
||||
==== Fix Requires:
|
||||
|
||||
Most -devel packages have a Requires equal to the Name-Version-Release (NVR)
|
||||
Most `-devel` packages have a `Requires:` equal to the Name-Version-Release (NVR)
|
||||
....
|
||||
%package -n %{rhel_name}-devel
|
||||
Requires: %{rhel_name}%{?_isa} = %{version}-%{release}
|
||||
....
|
||||
|
||||
If this were a perfect world, you could leave your -epel package like that. But it's not a perfect world, and there are many times you need to update your -epel package separate from the RHEL package being updated.
|
||||
If this were a perfect world, you could leave your `-epel` package like that.
|
||||
But it's not a perfect world, and there are many times you need to update your
|
||||
`-epel` package separate from the RHEL package being updated.
|
||||
|
||||
The following are two options. It is up to the -epel package maintainer to decide which is right for them, or perhaps do things your own way.
|
||||
The following are two options. It is up to the `-epel` package maintainer to
|
||||
decide which is right for them, or perhaps do things your own way.
|
||||
|
||||
===== Remove release
|
||||
|
||||
If your -epel package only has some unchanging headers, you usually do not need to keep completely in step with the RHEL release, only the version. If that is the case, simply remove the -%\{release} section.
|
||||
If your -epel package only has some unchanging headers, you usually do not need
|
||||
to keep completely in step with the RHEL release, only the version. If that is
|
||||
the case, simply remove the `-%\{release}` section.
|
||||
....
|
||||
%package -n %{rhel_name}-devel
|
||||
Requires: %{rhel_name}%{?_isa} = %{version}
|
||||
|
|
@ -99,7 +111,10 @@ Requires: %{rhel_name}%{?_isa} = %{version}
|
|||
|
||||
===== Rename release
|
||||
|
||||
If your -epel package has to be updated each time the RHEL package is updated, no matter what, one way to do this is with a %\{rhel_release} that goes along with your %\{rhel_name}. If you do this, your -epel release must be less than the RHEL release.
|
||||
If your `-epel` package has to be updated each time the RHEL package is updated,
|
||||
no matter what, one way to do this is with a `%\{rhel_release}` that goes along
|
||||
with your `%\{rhel_name}`. If you do this, your `-epel` release must be less than
|
||||
the RHEL release.
|
||||
....
|
||||
...
|
||||
%global rhel_name pycairo
|
||||
|
|
@ -116,8 +131,8 @@ Requires: %{rhel_name}%{?_isa} = %{version}-%{rhel_release}
|
|||
|
||||
==== ExcludeArch: (if needed)
|
||||
|
||||
Some sub-packages are only missing in some arches. If that is the case, then you should
|
||||
use ExcludeArch: to have your package only built on those arches you care about.
|
||||
Some sub-packages are only missing in some arches. If that is the case, then you should
|
||||
use `ExcludeArch:` to have your package only built on those arches you care about.
|
||||
|
||||
....
|
||||
# This is only for non-x86/POWER architectures
|
||||
|
|
@ -126,7 +141,7 @@ ExcludeArch: %{ix86} x86_64 %{power64}
|
|||
|
||||
==== Remove files shipped in RHEL
|
||||
|
||||
At the end of the %install section, remove all the files you will not be shipping.
|
||||
At the end of the `%install` section, remove all the files you will not be shipping.
|
||||
|
||||
....
|
||||
%install
|
||||
|
|
@ -139,16 +154,17 @@ rm -rf %{buildroot}%{python3_sitearch}
|
|||
==== Remove un-needed sections
|
||||
|
||||
* *Need to remove*
|
||||
** %files
|
||||
*** Remove all the %files sections you will not be shipping.
|
||||
*** Make sure any file listed in those sections is removed in the %install section.
|
||||
** `%files`
|
||||
*** Remove all the `%files` sections you will not be shipping.
|
||||
*** Make sure any file listed in those sections is removed in the `%install` section.
|
||||
|
||||
* *Optional remove*
|
||||
** %package and %description
|
||||
** %prep %post and other scripts
|
||||
** %check
|
||||
*** This really depends on what you are doing. If %check takes an hour, and all you need is a few headers, feel free to remove it. If the missing package has an actual program in it, leave it in.
|
||||
*** When in doubt, leave %check in.
|
||||
** `%package` and `%description`
|
||||
** `%prep`, `%post`, and other scripts
|
||||
** `%check`
|
||||
*** This really depends on what you are doing. If `%check` takes an hour, and all you need is a few headers, feel free to remove it.
|
||||
If the missing package has an actual program in it, leave it in.
|
||||
*** When in doubt, leave `%check` in.
|
||||
|
||||
|
||||
== Missing un-built examples
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ procedures have been setup.
|
|||
[[shared_guidelines]]
|
||||
== Shared guidelines
|
||||
|
||||
* You MUST name your source package <package>-epel
|
||||
* You MUST name your source package `<package>-epel`
|
||||
* You MUST NOT conflict with any RHEL packages or files
|
||||
|
||||
[[missing_built_sub-packages]]
|
||||
|
|
@ -36,9 +36,9 @@ Create an EPEL package that only has the missing packages, or missing arches.
|
|||
* A package review is not required, but it is a good idea to have someone look at the updated spec file.
|
||||
* If you need help building this, ask for help. We have xref:epel-packaging-examples.adoc#_missing_but_built_examples[some examples].
|
||||
* It qualifies for an exception to the package review process so you can request the repo with.
|
||||
** fedpkg request-repo --exception <package>-epel
|
||||
** `fedpkg request-repo --exception <package>-epel`
|
||||
* Once the repo is created, you must retire the rawhide branch to make it clear that this is an EPEL-only package and shouldn't be branched for future Fedora releases.
|
||||
** fedpkg retire 'EPEL-only package'
|
||||
** `fedpkg retire 'EPEL-only package'`
|
||||
* When/If the missing package(s) are added to RHEL CRB, retire your -epel package following the xref:epel-policy-retirement.adoc#process_package_in_rhel[EPEL retirement policy].
|
||||
|
||||
xref:epel-packaging-examples.adoc#_missing_but_built_examples[Short term examples and workflow]
|
||||
|
|
@ -57,7 +57,8 @@ More details on this can be found in the
|
|||
link:++https://docs.centos.org/en-US/stream-contrib/quickstart/#_1_file_an_issue++[CentOS contributor guide].
|
||||
* Be sure to say that it is impacting an EPEL build, and which package it is impacting.
|
||||
|
||||
....
|
||||
[,console]
|
||||
----
|
||||
Please add <sub-package> to CRB in RHEL9
|
||||
|
||||
I am building <my package> in EPEL9.
|
||||
|
|
@ -69,7 +70,7 @@ I am building <my package> in EPEL9.
|
|||
|
||||
(Optional)
|
||||
<my package> is important because <my company> uses it for <reason>
|
||||
....
|
||||
----
|
||||
|
||||
In the past, the default answer for a request like this was "no".
|
||||
But in mid-2021 the RHEL policy changed to allow the RHEL package
|
||||
|
|
@ -82,7 +83,7 @@ the sub-packages to the RHEL CRB repo.
|
|||
|
||||
You can create packages that supply missing sub-packages that were not built in RHEL but are built in Fedora.
|
||||
|
||||
In the past these were named <package>-extra, but these are now named <package>-epel to avoid confusion.
|
||||
In the past these were named <package>-extra, but these are now named `<package>-epel` to avoid confusion.
|
||||
|
||||
|
||||
xref:epel-packaging-examples.adoc#_missing_un_built_examples[Missing but un-built examples]
|
||||
|
|
|
|||
|
|
@ -47,8 +47,8 @@ announce the retirement and specific actions that users must
|
|||
take in order to continue using the software
|
||||
(e.g. install using `pip` or some other delivery mechanism).
|
||||
. link:++https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#_procedure++[Retire the package from EPEL].
|
||||
** fedpkg switch-branch epel8 (or whichever epel branch is correct)
|
||||
** fedpkg retire "REASON FOR RETIREMENT"
|
||||
** `fedpkg switch-branch epel8` (or whichever epel branch is correct)
|
||||
** `fedpkg retire "REASON FOR RETIREMENT"`
|
||||
|
||||
[[process_no_time_or_desire]]
|
||||
== Process: No time or desire
|
||||
|
|
@ -67,8 +67,8 @@ is anything special about the package, or urgent issues such as the package not
|
|||
announce the retirement and specific actions that users must take in order to continue using the software
|
||||
(e.g. install using `pip` or some other delivery mechanism).
|
||||
. link:++https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#_procedure++[Retire the package from EPEL].
|
||||
** fedpkg switch-branch epel8 (or whichever epel branch is correct)
|
||||
** fedpkg retire "REASON FOR RETIREMENT"
|
||||
** `fedpkg switch-branch epel8` (or whichever epel branch is correct)
|
||||
** `fedpkg retire "REASON FOR RETIREMENT"`
|
||||
|
||||
[[process_not_installable]]
|
||||
== Process: Not installable
|
||||
|
|
@ -89,5 +89,5 @@ If a package was never installable in an EPEL repo, try to fix the problem. If
|
|||
to retire the package from that EPEL branch / repo, you can.
|
||||
|
||||
. link:++https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#_procedure++[Retire the package from EPEL].
|
||||
** fedpkg switch-branch epel8 (or whichever epel branch is correct)
|
||||
** fedpkg retire "REASON FOR RETIREMENT"
|
||||
** `fedpkg switch-branch epel8` (or whichever epel branch is correct)
|
||||
** `fedpkg retire "REASON FOR RETIREMENT"`
|
||||
|
|
|
|||
|
|
@ -56,25 +56,25 @@ list discussions as the version of Red Hat Enterprise Linux that the
|
|||
Koji builders have access to.
|
||||
|
||||
* EPEL 10's leading minor version is built against CentOS Stream 10 repos
|
||||
** baseos
|
||||
** appstream
|
||||
** crb
|
||||
** `baseos`
|
||||
** `appstream`
|
||||
** `crb`
|
||||
* EPEL 10's trailing minor versions are built against Red Hat Enterprise Linux 10 channels
|
||||
** rhel-10-for-*-baseos-rpms
|
||||
** rhel-10-for-*-appstream-rpms
|
||||
** codeready-builder-for-rhel-10-*-rpms
|
||||
** `rhel-10-for-*-baseos-rpms`
|
||||
** `rhel-10-for-*-appstream-rpms`
|
||||
** `codeready-builder-for-rhel-10-*-rpms`
|
||||
* EPEL 9 Next is built against CentOS Stream 9 repos
|
||||
** baseos
|
||||
** appstream
|
||||
** crb
|
||||
** `baseos`
|
||||
** `appstream`
|
||||
** `crb`
|
||||
* EPEL 9 is built against Red Hat Enterprise Linux 9 channels
|
||||
** rhel-9-for-*-baseos-rpms
|
||||
** rhel-9-for-*-appstream-rpms
|
||||
** codeready-builder-for-rhel-9-*-rpms
|
||||
** `rhel-9-for-*-baseos-rpms`
|
||||
** `rhel-9-for-*-appstream-rpms`
|
||||
** `codeready-builder-for-rhel-9-*-rpms`
|
||||
* EPEL 8 is built against Red Hat Enterprise Linux 8 channels
|
||||
** rhel-8-for-*-baseos-rpms
|
||||
** rhel-8-for-*-appstream-rpms
|
||||
** codeready-builder-for-rhel-8-*-rpms
|
||||
** `rhel-8-for-*-baseos-rpms`
|
||||
** `rhel-8-for-*-appstream-rpms`
|
||||
** `codeready-builder-for-rhel-8-*-rpms`
|
||||
|
||||
EPEL packages which are known to also exist in other RHEL channels
|
||||
should keep a lower `epoch:version-release` (EVR) than the RHEL package.
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ include::partial$attributes.adoc[]
|
|||
|
||||
= The EPEL testing repository
|
||||
|
||||
The *epel-testing* repository contains updates scheduled to be released
|
||||
The `*epel-testing*` repository contains updates scheduled to be released
|
||||
for the maintained releases of EPEL. User testing and feedback provided
|
||||
via link:++https://bodhi.fedoraproject.org++[Bodhi], on the
|
||||
link:++https://admin.fedoraproject.org/mailman/listinfo/epel-devel++[epel-devel]
|
||||
|
|
@ -72,24 +72,24 @@ in the Bodhi system. First of all, if any test update package works
|
|||
worse for you in any respect than the pre-update version did, this is a
|
||||
problem that should be communicated to the developers. Secondly, when
|
||||
you click on a certain update, you will see a screen with more
|
||||
information on the update. The _Details_ section should give you
|
||||
information on the update. The `Details` section should give you
|
||||
information on what the update is intended to fix. You should, if
|
||||
possible, test that the update does indeed fix the issues it claims to
|
||||
fix.
|
||||
|
||||
You can give your feedback on a test update by using the
|
||||
link:++https://bodhi.fedoraproject.org++[Bodhi web interface]. There is a _Login_
|
||||
link:++https://bodhi.fedoraproject.org++[Bodhi web interface]. There is a `Login`
|
||||
link in the left-hand sidebar. Log in using your Fedora account. If you
|
||||
don't have a Fedora account, you can
|
||||
link:++https://admin.fedoraproject.org/accounts/user/new++[create an account
|
||||
here]. Once you are logged in, you will be able to leave a comment on
|
||||
the update. Underneath the comment box are three options: _Untested_,
|
||||
_Works for me_, and _Does not work_. For a guide on when to leave each
|
||||
the update. Underneath the comment box are three options: `Untested`,
|
||||
`Works for me`, and `Does not work`. For a guide on when to leave each
|
||||
type of feedback, read the
|
||||
link:++https://fedoraproject.org/wiki/QA:Update_feedback_guidelines++[update feedback guidelines].
|
||||
|
||||
Each _Works for me_ adds 1 to the test update's _karma_, while each
|
||||
_Does not work_ subtracts 1 from it. _Untested_ leaves the karma
|
||||
Each `Works for me` adds 1 to the test update's karma, while each
|
||||
`Does not work` subtracts 1 from it. `Untested` leaves the karma
|
||||
unchanged. Usually, test updates with karma of 3 are automatically sent
|
||||
out as full official updates, while test updates with karma of -3 are
|
||||
automatically withdrawn from the testing repository. As you can see,
|
||||
|
|
|
|||
|
|
@ -1,13 +0,0 @@
|
|||
include::partial$attributes.adoc[]
|
||||
:experimental:
|
||||
|
||||
= Getting a Fedora package in EPEL
|
||||
|
||||
[[procedure_for_getting_a_package_in_epel]]
|
||||
== Procedure for getting a package in EPEL
|
||||
|
||||
If you are already a Fedora contributor, for your own package use the
|
||||
xref:package-maintainers::Package_Maintenance_Guide.adoc[standard procedures] for requesting a new branch using `+fedpkg request-branch+`.
|
||||
|
||||
If you'd like to see a Fedora package in EPEL that is not yours, follow the
|
||||
xref:epel-package-request.adoc[EPEL package request steps].
|
||||
|
|
@ -7,8 +7,11 @@ To enable the EPEL repository on your system,
|
|||
install the appropriate release package as described below.
|
||||
These packages contain the repository configuration and public package signing key.
|
||||
|
||||
CAUTION: Some EPEL packages depend on packages from repositories that are not enabled by default.
|
||||
[CAUTION]
|
||||
====
|
||||
Some EPEL packages depend on packages from repositories that are not enabled by default.
|
||||
Take note of the additional repositories being enabled in the instructions on this page.
|
||||
====
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
|
|
@ -82,7 +85,7 @@ that target RHEL 9 compatibility.
|
|||
We cannot list specific instructions for all such distributions,
|
||||
but in general the steps needed should look similar to the steps for RHEL 9.
|
||||
First enable the distribution's equivalent of the CRB repository,
|
||||
then install the epel-release package.
|
||||
then install the `epel-release` package.
|
||||
|
||||
[,console]
|
||||
----
|
||||
|
|
@ -116,7 +119,7 @@ that target RHEL 8 compatibility.
|
|||
We cannot list specific instructions for all such distributions,
|
||||
but in general the steps needed should look similar to the steps for RHEL 8.
|
||||
First enable the distribution's equivalent of the PowerTools/CRB repository,
|
||||
then install the epel-release package.
|
||||
then install the `epel-release` package.
|
||||
|
||||
[,console]
|
||||
----
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue