Change all headings to standard case
This commit is contained in:
parent
748ad82300
commit
6bb0db9b46
18 changed files with 65 additions and 62 deletions
|
|
@ -1,7 +1,7 @@
|
|||
include::partial$attributes.adoc[]
|
||||
:experimental:
|
||||
|
||||
= History and Philosophy of EPEL (Extra Packages for Enterprise Linux)
|
||||
= History and philosophy of EPEL (Extra Packages for Enterprise Linux)
|
||||
|
||||
[[history_and_philosophy_of_epel_extra_packages_for_enterprise_linux]]
|
||||
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ created you can merge commits from other branches and submit a build
|
|||
just like you would for other EPEL or Fedora branches.
|
||||
|
||||
[[example_workflow]]
|
||||
== Example Workflow
|
||||
== Example workflow
|
||||
|
||||
The workflow for building and releasing a package in EPEL Next is
|
||||
intentionally very similar to EPEL itself.
|
||||
|
|
|
|||
|
|
@ -1,9 +1,12 @@
|
|||
include::partial$attributes.adoc[]
|
||||
:experimental:
|
||||
|
||||
= EPEL PLAYGROUND
|
||||
= EPEL Playground
|
||||
|
||||
[WARNING]
|
||||
====
|
||||
*EPEL Playground was shut down in January 2022*
|
||||
====
|
||||
|
||||
EPEL 8 Playground was a place that developers and maintainers could "play around"
|
||||
with updated, or changed packages in epel. EPEL Playground never really worked
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ Fedora packages they maintain on Red Hat Enterprise Linux (RHEL) and its
|
|||
compatible derivatives.
|
||||
|
||||
[[goals_of_the_epel_effort]]
|
||||
== Goals of the EPEL Effort
|
||||
== Goals of the EPEL effort
|
||||
|
||||
Make high quality packages that have been developed, tested, and
|
||||
improved in Fedora available for RHEL and compatible derivatives such as
|
||||
|
|
@ -30,10 +30,10 @@ synchronized with Fedora, maintain add-on documents for EPEL that
|
|||
describe the differences and the reasons for them.
|
||||
|
||||
[[who_needs_these_packages]]
|
||||
== Who Needs These Packages
|
||||
== Who needs these packages
|
||||
|
||||
[[enterprise_linux_useradministrator_perspective]]
|
||||
=== Enterprise Linux User/Administrator Perspective
|
||||
=== Enterprise Linux user/administrator perspective
|
||||
|
||||
Every user and admin has experienced at least one desired package not
|
||||
being included and supported in RHEL. This project gives you a place to
|
||||
|
|
@ -46,7 +46,7 @@ your work and have your fun, Fedora enterprise packages are a good
|
|||
method to build support and community around particular software needs.
|
||||
|
||||
[[community_perspective]]
|
||||
=== Community Perspective
|
||||
=== Community perspective
|
||||
|
||||
Many members of the Fedora community
|
||||
are also users/administrators of Enterprise Linux distributions that are derived from Fedora,
|
||||
|
|
@ -55,7 +55,7 @@ Everyone has their own reasons for promoting a particular piece of software.
|
|||
EPEL packages are the best way to gain users and support from Enterprise Linux users.
|
||||
|
||||
[[isvihv_perspective]]
|
||||
=== ISV/IHV Perspective
|
||||
=== ISV/IHV perspective
|
||||
|
||||
The benefits of building upon EPEL as an ISV or IHV have great
|
||||
potential. If your software package currently packages its own copies of
|
||||
|
|
@ -90,7 +90,7 @@ open source development process, along with advancing the technology in
|
|||
parallel in Fedora.
|
||||
|
||||
[[academia_perspective]]
|
||||
== Academia Perspective
|
||||
== Academia perspective
|
||||
|
||||
Aside from the usual need for software that wasn't included in RHEL,
|
||||
there is a large opportunity for academia to provide students with
|
||||
|
|
@ -105,7 +105,7 @@ managing feature enhancements, bug fixes, and security updates across
|
|||
all communities.
|
||||
|
||||
[[red_hat_perspective]]
|
||||
== Red Hat Perspective
|
||||
== Red Hat perspective
|
||||
|
||||
This is a simple imagination exercise.
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ include::partial$attributes.adoc[]
|
|||
|
||||
There are many ways to join in and help out with EPEL. A few are listed below. If you think of another way to help out, feel free to bring it up on our mailing list or at our weekly meetings.
|
||||
|
||||
== Maintaining Packages ==
|
||||
== Maintaining packages ==
|
||||
|
||||
Package Maintainers update, fix bugs and improve packages in the EPEL collection. See the xref:epel-package-maintainers.adoc[EPEL Package Maintainers] page for more information on roles and how to join this group.
|
||||
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ your duty to your employer and to Fedora to make sure that your package
|
|||
lives on in case you do not.
|
||||
|
||||
[[generic_job_description]]
|
||||
== Generic Job Description
|
||||
== Generic job description
|
||||
|
||||
*EPEL Package Maintainer*
|
||||
|
||||
|
|
@ -49,7 +49,7 @@ the synchronization against at least the one specific version of Red Hat
|
|||
Enterprise Linux.
|
||||
|
||||
[[job_duties]]
|
||||
=== Job Duties
|
||||
=== Job duties
|
||||
|
||||
* Interact with upstream
|
||||
* Interact with Fedora and EPEL sub-group
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
include::partial$attributes.adoc[]
|
||||
:experimental:
|
||||
|
||||
= EPEL Package Maintainers
|
||||
= EPEL package maintainers
|
||||
|
||||
[[epel_package_maintainers]]
|
||||
|
||||
|
|
@ -11,7 +11,7 @@ to the collection as needed. EPEL packagers are members of the Fedora
|
|||
"packagers" group.
|
||||
|
||||
[[joining_the_epel_package_maintainers]]
|
||||
== Joining the EPEL Package Maintainers
|
||||
== Joining the EPEL package maintainers
|
||||
|
||||
There are several ways you can join the EPEL package maintainer group:
|
||||
|
||||
|
|
@ -45,7 +45,7 @@ xref:epel-package-request.adoc#stalled_epel_requests[stalled EPEL Request proced
|
|||
and maintain it yourself.
|
||||
|
||||
[[epel_policies_and_guidelines]]
|
||||
== EPEL Policies and Guidelines
|
||||
== EPEL policies and guidelines
|
||||
|
||||
Where possible, EPEL tries to use and follow any applicable Fedora
|
||||
guidelines. There are of course some exceptions due to older packages
|
||||
|
|
@ -54,7 +54,7 @@ all such guidelines at the xref:epel-packaging.adoc[EPEL Packaging Guidelines]
|
|||
page.
|
||||
|
||||
[[epel_updates_policy]]
|
||||
== EPEL Updates policy
|
||||
== EPEL updates policy
|
||||
|
||||
EPEL strives to provide updates that are compatible and stable to
|
||||
compliment the Enterprise Linux packages it's built on. You can find a
|
||||
|
|
@ -70,7 +70,7 @@ xref:epel-rhel-entitlements.adoc[this page]
|
|||
for information about getting a free RHEL subscription for EPEL package maintenance.
|
||||
|
||||
[[new_package_wish_list]]
|
||||
== New Package Wish List
|
||||
== New package wish list
|
||||
|
||||
The best way to get a new package into EPEL is to first get it added to
|
||||
Fedora. You can add such packages to the
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
include::partial$attributes.adoc[]
|
||||
:experimental:
|
||||
|
||||
= EPEL Package Request
|
||||
= Requesting a new package in EPEL
|
||||
|
||||
When requesting a Fedora package for EPEL, the steps are a little different
|
||||
depending on your ability or willingness to help.
|
||||
|
|
@ -81,7 +81,7 @@ 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.
|
||||
|
||||
[[end_users]]
|
||||
=== Consumers / End Users
|
||||
=== Consumers/end users
|
||||
|
||||
Clear out Description and put
|
||||
|
||||
|
|
@ -99,7 +99,7 @@ If there is no action on the bug after two more weeks, send an email to https://
|
|||
who would like to package and maintain your package on epel. Be sure to include the Bugzilla URL in your email.
|
||||
|
||||
[[fedora_packagers]]
|
||||
=== Fedora / EPEL Packagers
|
||||
=== Fedora/EPEL packagers
|
||||
|
||||
Clear out Description and put
|
||||
|
||||
|
|
@ -138,7 +138,7 @@ I am requesting <my_FAS_id> be given commit permissions so that I might branch a
|
|||
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
|
||||
=== EPEL packagers SIG members
|
||||
|
||||
Clear out Description and put
|
||||
|
||||
|
|
@ -185,7 +185,7 @@ I am a member of the epel-packagers-sig and I am requesting epel-packagers-sig b
|
|||
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
|
||||
== Stalled EPEL requests
|
||||
|
||||
There are times that an EPEL / Fedora package maintainer isn't
|
||||
responding to an EPEL package request. If a different packager would
|
||||
|
|
|
|||
|
|
@ -1,14 +1,14 @@
|
|||
include::partial$attributes.adoc[]
|
||||
:experimental:
|
||||
|
||||
= EPEL Packaging Examples
|
||||
= EPEL packaging examples
|
||||
|
||||
== Missing But Built Examples
|
||||
== Missing-but-built examples
|
||||
|
||||
These examples are for the xref:epel-policy-missing-sub-packages.adoc#short_term[Missing RHEL Sub-Packages / Missing Built Sub-Packages
|
||||
/ Short Term policy].
|
||||
|
||||
=== Missing But Built Workflow
|
||||
=== Missing-but-built workflow
|
||||
|
||||
This is an example workflow.
|
||||
|
||||
|
|
@ -38,11 +38,11 @@ This is an example workflow.
|
|||
* *fedpkg build*
|
||||
* *fedpkg update*
|
||||
|
||||
=== Missing But Built Spec Examples
|
||||
=== Missing-but-built spec examples
|
||||
|
||||
These examples should help you convert your RHEL spec file to a -epel spec file.
|
||||
|
||||
==== Header / Top of Spec
|
||||
==== 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.
|
||||
|
|
@ -152,8 +152,8 @@ rm -rf %{buildroot}%{python3_sitearch}
|
|||
*** When in doubt, leave %check in.
|
||||
|
||||
|
||||
== Missing Un-Built Examples
|
||||
== Missing un-built examples
|
||||
|
||||
These examples are for the xref:epel-policy-missing-sub-packages.adoc#missing_un-built_sub-packages[Missing RHEL Sub-Packages / Missing Un-Built Sub-Packages policy].
|
||||
|
||||
Put Examples and Tips Here
|
||||
//TODO:Put Examples and Tips Here
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
include::partial$attributes.adoc[]
|
||||
:experimental:
|
||||
|
||||
= EPEL Packaging
|
||||
= EPEL packaging
|
||||
|
||||
This page contains guidelines which are not relevant
|
||||
or are no longer relevant to Fedora,
|
||||
|
|
@ -15,7 +15,7 @@ As a reminder, these guidelines only apply to EPEL packages, not to
|
|||
Fedora packages.
|
||||
|
||||
[[package_dependencies]]
|
||||
== Package Dependencies
|
||||
== Package dependencies
|
||||
|
||||
All EPEL package dependencies (build-time or runtime)
|
||||
MUST ALWAYS be satisfiable within the Target Base
|
||||
|
|
@ -75,7 +75,7 @@ these to EPEL8, so that fedora packages are easily able to build on
|
|||
EPEL8 without any changes. When EPEL 8 becomes old enough, that these
|
||||
backports are not feasible and/or wanted, we will list them here.
|
||||
|
||||
== RPM Macros
|
||||
== RPM macros
|
||||
|
||||
Not all macros defined in (or built into) existing Fedora packages
|
||||
will work when a spec is converted for use in EPEL. https://src.fedoraproject.org/rpms/epel-rpm-macros/[epel-rpm-macros]
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
include::partial$attributes.adoc[]
|
||||
:experimental:
|
||||
|
||||
= Missing RHEL Sub-Packages
|
||||
= Missing RHEL sub-packages
|
||||
|
||||
When a RHEL source package is built, it often creates more than one binary package. These
|
||||
extra packages are generally called sub-packages.
|
||||
|
|
@ -18,16 +18,16 @@ To solve the problem of missing built and un-built sub-packages, the following p
|
|||
procedures have been setup.
|
||||
|
||||
[[shared_guidelines]]
|
||||
== Shared Guidelines
|
||||
== Shared guidelines
|
||||
|
||||
* You MUST name your source package <package>-epel
|
||||
* You MUST NOT conflict with any RHEL packages or files
|
||||
|
||||
[[missing_built_sub-packages]]
|
||||
== Missing Built Sub-Packages
|
||||
== Missing built sub-packages
|
||||
|
||||
[[short_term]]
|
||||
=== Short Term
|
||||
=== Short term
|
||||
|
||||
Create an EPEL package that only has the missing packages, or missing arches.
|
||||
|
||||
|
|
@ -44,7 +44,7 @@ Create an EPEL package that only has the missing packages, or missing arches.
|
|||
xref:epel-packaging-examples.adoc#_missing_but_built_examples[Short Term Examples and Workflow]
|
||||
|
||||
[[long_term]]
|
||||
=== Long Term
|
||||
=== Long term
|
||||
|
||||
Request the package be added to the appropriate RHEL CRB repository.
|
||||
|
||||
|
|
@ -78,7 +78,7 @@ the answer might be "no", but many maintainers are choosing to add
|
|||
the sub-packages to the RHEL CRB repo.
|
||||
|
||||
[[missing_un-built_sub-packages]]
|
||||
== Missing Un-Built Sub-Packages
|
||||
== Missing un-built sub-packages
|
||||
|
||||
You can create packages that supply missing sub-packages that were not built in RHEL but are built in Fedora.
|
||||
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ is going to be in RHEL. It should also say which RHEL release it will be in (e.
|
|||
** fedpkg retire "REASON FOR RETIREMENT"
|
||||
|
||||
[[process_security_reasons]]
|
||||
== Process: Security Reasons
|
||||
== Process: Security reasons
|
||||
|
||||
If a package has a severe security issue, and the fix cannot be backported, usually
|
||||
this can be fixed xref:epel-policy-incompatible-upgrades.adoc#process_for_incompatible_upgrades[with
|
||||
|
|
@ -51,7 +51,7 @@ take in order to continue using the software
|
|||
** fedpkg retire "REASON FOR RETIREMENT"
|
||||
|
||||
[[process_no_time_or_desire]]
|
||||
== Process: No Time or Desire
|
||||
== Process: No time or desire
|
||||
|
||||
EPEL is run and maintained by many volunteers. A person's life, job,
|
||||
and priorities change over time. It is natural that a time might come that you no
|
||||
|
|
@ -71,19 +71,19 @@ announce the retirement and specific actions that users must take in order to co
|
|||
** fedpkg retire "REASON FOR RETIREMENT"
|
||||
|
||||
[[process_not_installable]]
|
||||
== Process: Not Installable
|
||||
== Process: Not installable
|
||||
|
||||
There are times that packages are not installable in EPEL. These packages fall into two categories.
|
||||
Packages that once were installable, but no longer are. Packages that were never installable.
|
||||
|
||||
[[process_once_installable]]
|
||||
=== Process: Once Installable
|
||||
=== Process: Once installable
|
||||
|
||||
If a package was once installable, but no longer is, try to fix the problem. If you cannot, or you do not have the
|
||||
time or desire to fix it, follow the https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/#process_no_time_or_desire[No Time or Desire policy]
|
||||
|
||||
[[process_never_installable]]
|
||||
=== Process: Never Installable
|
||||
=== Process: Never installable
|
||||
|
||||
If a package was never installable in an EPEL repo, try to fix the problem. If you cannot fix the problem and wish
|
||||
to retire the package from that EPEL branch / repo, you can.
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@ In 2023 the committee decided that members would be elected. The first election
|
|||
* Thorsten Leemhuis - Start: February 2007 End: February 2008
|
||||
|
||||
[[committee_member_selection]]
|
||||
=== Committee Member Selection
|
||||
=== Committee member selection
|
||||
|
||||
From EPEL's beginning (2007) until 2024, committee members were based on the most active members when new seats needed to be filled.
|
||||
Starting in 2024, Steering Committee members will be elected for two year terms.
|
||||
|
|
@ -52,22 +52,22 @@ EPEL Streeing Committee elections will be part of the https://docs.fedoraproject
|
|||
EPEL committee elections will occur during the first Fedora election cycle of a calendar year.
|
||||
|
||||
[[committee_members]]
|
||||
== Committee Chair
|
||||
== Committee chair
|
||||
|
||||
[[committee_chair_history]]
|
||||
=== Current Committee Members
|
||||
=== Current committee members
|
||||
|
||||
* Troy Dawson (tdawson ) Start: October 2020
|
||||
* Stephen J Smoogen ( smooge ) Start: February 2008 End: October 2020
|
||||
* Thorsten Leemhuis - Start: February 2007 End: February 2008
|
||||
|
||||
[[committee_chair_selection]]
|
||||
=== Committee Chair Selection
|
||||
=== Committee chair selection
|
||||
From EPEL's beginning (2007) until 2024 the committee chair was a committee volunteer who stayed as chair until they stepped down.
|
||||
Starting in 2024, the committee chair will be elected each year, by the committee, after the committee elections.
|
||||
|
||||
[[committee_meeting]]
|
||||
== Committee Meeting
|
||||
== Committee meeting
|
||||
|
||||
The place and time for the EPEL Steering Committee meeting can be found in the
|
||||
xref:epel-communication.adoc[Communicating with EPEL] section of our documentation
|
||||
|
|
@ -75,7 +75,7 @@ xref:epel-communication.adoc[Communicating with EPEL] section of our documentati
|
|||
The meeting is public and everyone is invited.
|
||||
|
||||
[[committee_meeting_voting]]
|
||||
=== Committee Meeting Voting
|
||||
=== Committee meeting voting
|
||||
|
||||
The EPEL Steering Committee tracks ongoing decisions using the
|
||||
https://pagure.io/epel/issues[EPEL ticketing system].
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
include::partial$attributes.adoc[]
|
||||
:experimental:
|
||||
|
||||
= EPEL Updates Policy
|
||||
= EPEL updates policy
|
||||
|
||||
[[epel_updates_policy]]
|
||||
|
||||
|
|
@ -10,7 +10,7 @@ package collection. For general EPEL package guidelines, refer to the
|
|||
xref:epel-policy.adoc[EPEL Guidelines and Policy] page.
|
||||
|
||||
[[stable_releases]]
|
||||
== Stable Releases
|
||||
== Stable releases
|
||||
|
||||
* All updates MUST spend at least 1 week in the testing repository, or
|
||||
+3 karma from testers.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
include::partial$attributes.adoc[]
|
||||
:experimental:
|
||||
|
||||
= Packaging Guidelines and Policies for EPEL
|
||||
= Packaging guidelines and policies for EPEL
|
||||
|
||||
[[packaging_guidelines_and_policies_for_epel]]
|
||||
|
||||
|
|
@ -111,7 +111,7 @@ testing time for packages, refer to the xref:epel-policy-updates.adoc[EPEL
|
|||
Updates Policy].
|
||||
|
||||
[[workflow_examples_information]]
|
||||
== Workflow examples / Information
|
||||
== Workflow examples/information
|
||||
|
||||
* Maintainer builds the package.
|
||||
* Maintainer submits an update for testing using bodhi.
|
||||
|
|
@ -121,7 +121,7 @@ will promote the package to stable.
|
|||
* Pushes for both testing and stable take place daily.
|
||||
|
||||
[[guidelines_and_backgrounds_for_this_policy]]
|
||||
== Guidelines and Backgrounds for this policy
|
||||
== Guidelines and backgrounds for this policy
|
||||
|
||||
[[some_examples_of_what_package_updates_that_are_fine_or_not]]
|
||||
=== Some examples of what package updates that are fine or not
|
||||
|
|
@ -179,7 +179,7 @@ compat package that provides the current soname at the same time you
|
|||
ship the new soname.
|
||||
|
||||
[[security_updates]]
|
||||
==== Security Updates
|
||||
==== Security updates
|
||||
|
||||
Security updates should be marked as such in bodhi and will be pushed to
|
||||
stable. Because of this you should always try and make as few changes as
|
||||
|
|
@ -247,7 +247,7 @@ differences with the Fedora Packaging Guidelines on the
|
|||
xref:epel-packaging.adoc[EPEL Packaging] page.
|
||||
|
||||
[[policy_for_conflicting_packages]]
|
||||
== Policy for Conflicting Packages
|
||||
== Policy for conflicting packages
|
||||
|
||||
xref:epel-faq.adoc#does_epel_replace_packages_provided_within_red_hat_enterprise_linux[Per
|
||||
RHEL Release Package Conflict Channel Exclusions]
|
||||
|
|
@ -288,7 +288,7 @@ This is allowed both between EPEL packages and between EPEL and RHEL packages.
|
|||
The latter is an explicit exception to the general rule for EPEL packages to not conflict with target base RHEL packages.
|
||||
|
||||
[[policy_for_orphan_and_retired_packages]]
|
||||
== Policy for Orphan and Retired Packages
|
||||
== Policy for orphan and retired packages
|
||||
|
||||
EPEL follows the
|
||||
xref:fesco::Policy_for_orphan_and_retired_packages.adoc[Fedora
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
include::partial$attributes.adoc[]
|
||||
:experimental:
|
||||
|
||||
= EPEL Testing
|
||||
= EPEL testing
|
||||
|
||||
The *epel-testing* repository contains updates scheduled to be released
|
||||
for the maintained releases of EPEL. User testing and feedback provided
|
||||
|
|
|
|||
|
|
@ -3,8 +3,8 @@ include::partial$attributes.adoc[]
|
|||
|
||||
= Getting a Fedora package in EPEL
|
||||
|
||||
[[the_procedure_for_getting_a_package_in_epel]]
|
||||
== The procedure for getting a 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+`.
|
||||
|
|
|
|||
|
|
@ -103,7 +103,7 @@ dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.r
|
|||
|
||||
[WARNING]
|
||||
====
|
||||
*THESE ARE NO LONGER SUPPORTED*
|
||||
*End-of-life releases are no longer supported.*
|
||||
====
|
||||
|
||||
NOTE: Due to major security changes in SSL in the last 10 years, older
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue