epel/docs
7
0
Fork 6
Code Pull requests 4 Projects Activity

Fix links

Browse source
This commit is contained in:
Troy Dawson 2021-08-24 10:15:04 -07:00
commit 7724a1754b
7 changed files with 188 additions and 18 deletions
Download patch file Download diff file Expand all files Collapse all files

2
modules/ROOT/nav.adoc
View file

@ -1,5 +1,5 @@
* xref:epel-about.adoc[About]
** xref:epel-about-history-philosophy.adocgrep [History and Philosophy]
** xref:epel-about-history-philosophy.adoc[History and Philosophy]
** xref:epel-about-next.adoc[EPEL-Next]
** xref:epel-about-playground.adoc[EPEL-Playground]
* xref:epel-policy.adoc[Guidelines and Policies]

1
modules/ROOT/pages/epel-about-history-philosophy.adoc
View file

@ -1,6 +1,5 @@
include::partial$attributes.adoc[]
= History and Philosophy of EPEL (Extra Packages for Enterprise Linux)
:toc:
[[history_and_philosophy_of_epel_extra_packages_for_enterprise_linux]]

8
modules/ROOT/pages/epel-about-next.adoc
View file

@ -97,7 +97,7 @@ rebuilt in EPEL yet.
[[when_i_request_an_epel8_branch_will_an_epel8_next_branch_be_requested_automatically]]
=== When I request an epel8 branch, will an epel8-next branch be requested automatically?
No. That is something that used to happen for link:EPEL/Playground[EPEL
No. That is something that used to happen for xref:epel-about-playground#[EPEL
Playground]. Most maintainers didn't like it. Both EPEL Next and EPEL
Playground are now opt-in.
@ -105,13 +105,13 @@ Playground are now opt-in.
=== Can I use EPEL Next to provide a newer version of a package than what's in EPEL?
EPEL Next is bound by the same
link:EPEL/GuidelinesAndPolicies[guidelines and policies] as regular
xref:epel-policy#[guidelines and policies] as regular
EPEL. If a version upgrade is inappropriate for EPEL, it's inappropriate
for EPEL Next. If a version upgrade is unavoidable because of upcoming
changes in RHEL, then you must follow the
link:EPEL_incompatible_upgrades_policy[incompatible upgrades process].
xref:epel-policy-incompatible-upgrades#[incompatible upgrades process].
If you want to be able to change the version whenever you feel like it,
take a look at link:EPEL/Playground[EPEL Playground].
take a look at xref:epel-about-playground#developers_maintainers[EPEL Playground].
[[why_is_the_package_im_looking_for_in_epel_but_not_in_epel_next]]
=== Why is the package I'm looking for in EPEL but not in EPEL Next?

4
modules/ROOT/pages/epel-policy-updates.adoc
View file

@ -6,7 +6,7 @@ include::partial$attributes.adoc[]
This document describes the policy for updates to packages in the EPEL
package collection. For general EPEL package guidelines, refer to the
link:EPEL/GuidelinesAndPolicies[EPEL Guidelines and Policy] page.
xref:epel-policy#[EPEL Guidelines and Policy] page.
[[beta_releases]]
== Beta Releases
@ -35,7 +35,7 @@ it's stable phase the follow applies:
intervention to keep the package functioning after update.
* Major updates with changes to user experience are to be avoided. If
they cannot be avoided, the link:EPEL_incompatible_upgrades_policy[EPEL
they cannot be avoided, the xref:epel-policy-incompatible-upgrades#[EPEL
incompatible upgrades policy] MUST be followed. This includes two
separate announcements to the epel-announce mailing list.

156
modules/ROOT/pages/epel-testing.adoc Normal file
View file

@ -0,0 +1,156 @@
include::partial$attributes.adoc[]
= EPEL Testing
:toc:
The *epel-testing* repository contains updates scheduled to be released
for the maintained releases of EPEL. User testing and feedback provided
via http://bodhi.fedoraproject.org[Bodhi], on the
https://admin.fedoraproject.org/mailman/listinfo/epel-devel[epel-devel]
mailing list and the relevant http://bugzilla.redhat.com[Bugzilla] is
vital to ensure that good updates are released quickly and bad ones kept
away from release.
[[using_the_epel_testing_repository]]
== Using the epel-testing repository
[[enabling_the_repository_permanently]]
=== Enabling the repository permanently
The following command will enable the updates testing repository
permanently
....
yum-config-manager --enable epel-testing
....
Use yum repolist to verify. If you wish to disable it again, run the
following command
....
yum-config-manager --disable epel-testing
....
Tip: yum distro-sync will sync the packages to the versions available in
the repository and might be useful to run after you disable the testing
repository to downgrade packages back to the stable versions.
Note that yum-config-manager command is available as part of yum-utils
package and should be installed by default, at least on RHEL >= 6. On
older releases, or if yum-config-manager is not available, you may need
to edit the `+/etc/yum.repos.d/epel-testing.repo+` file manually and set
`+enabled=1+`.
[[enabling_the_repository_temporarily]]
=== Enabling the repository temporarily
If you'd rather not enable the epel-testing repository permanently but
just use it on a case-by-case basis, you can do this with _yum_. The
command:
....
yum update --enablerepo=epel-testing
....
will update the entire system using packages from the epel-testing
repository, while the command:
....
yum install <foo> --enablerepo=epel-testing
....
will install or update only the package named from the epel-testing
repository.
[[what_to_test_testing_and_reporting_results]]
== What to test, testing, and reporting results
The http://bodhi.fedoraproject.org[Bodhi] system is used to track and
collate feedback on testing updates. All testing updates will be shown
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 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
http://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
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
type of feedback, read the 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
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,
your testing and feedback is vital to make sure that good updates are
released quickly and bad ones don't get out to the general public.
[[note_on_using_dnf_with_epel_testing_and_dependency_errors_epel_7_only]]
== Note on using http://dnf.baseurl.org/[DNF] with epel-testing and dependency errors (EPEL 7 only)
If you use the _DNF_ tool rather than _yum_, note that unlike yum, it
does not notify you of dependency errors in the set of available updates
by default. yum will, by default, print some information about the
dependency errors, and then fail the update: you have to run to install
all the updates that do _not_ have dependency errors. _DNF_ essentially
does by default, and silently - it will install all updates that do not
have dependency errors, and not tell you about those that do.
To use dnf to spot updates with dependency errors, you can run , which
should act like yum's default behaviour.
[[enabling_the_repository_permanently_dnf]]
=== Enabling the repository permanently dnf
The following command will enable the updates testing repository
permanently
....
dnf config-manager --set-enabled epel-testing
....
Use dnf repolist to verify. If you wish to disable it again, run the
following command
....
dnf config-manager --set-disable epel-testing
....
Tip: dnf distro-sync will sync the packages to the versions available in
the repository and might be useful to run after you disable the testing
repository to downgrade packages back to the stable versions.
[[enabling_the_repository_temporarily_dnf]]
== Enabling the repository temporarily dnf
If you'd rather not enable the epel-testing repository permanently but
just use it on a case-by-case basis, you can do this with _dnf_. The
command:
....
dnf upgrade --enablerepo=epel-testing
....
will update the entire system using packages from the epel-testing
repository, while the command:
....
dnf install <foo> --enablerepo=epel-testing
....
will install or update only the package named from the epel-testing
repository.
[[see_also]]
== See also
* https://fedoraproject.org/wiki/Bodhi[Bodhi Guide]

3
modules/ROOT/pages/fedora-package-in-epel.adoc
View file

@ -37,8 +37,7 @@ package. These packagers can then request branches through bugzilla and
take over the package.
If the maintainer is not responsive, follow the process for a
link:EPEL/GuidelinesAndPolicies#Stalled_EPEL_Requests[stalled EPEL
request].
xref:epel-policy#stalled_epel_requests[stalled EPEL request].
== Templates

32
modules/ROOT/pages/index.adoc
View file

@ -33,6 +33,10 @@ repositories:
`+ # yum install +`https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm[`+https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm+`]
* CentOS Stream 8:
`+ # dnf install epel-release
* on RHEL 8 it is required to also enable the
codeready-builder-for-rhel-8-*-rpms repository since EPEL packages may
depend on packages from it:
@ -50,7 +54,7 @@ since EPEL packages may depend on packages from it:
Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special
Interest Group that creates, maintains, and manages a high quality set
of additional packages for Enterprise Linux, including, but not limited
to, link:Red_Hat_Enterprise_Linux[ Red Hat Enterprise Linux] (RHEL),
to, https://docs.fedoraproject.org/en-US/quick-docs/fedora-and-red-hat-enterprise-linux/index.html[ Red Hat Enterprise Linux] (RHEL),
CentOS and Scientific Linux (SL), Oracle Linux (OL).
EPEL packages are usually based on their Fedora counterparts and will
@ -61,12 +65,23 @@ manager and more.
Learn more about EPEL in the following pages:
* link:EPEL/FAQ[ EPEL FAQ]
* link:epel-faq[ EPEL FAQ]
* link:About_EPEL[About EPEL]
* link:epel-about[About EPEL]
* link:EPEL/GuidelinesAndPolicies[EPEL Guidelines and Policies]
* link:epel-policy[EPEL Guidelines and Policies]
[[what_is_epel_next]]
== What is EPEL-Next?
EPEL packages are built against RHEL. EPEL Next packages are built against CentOS Stream.
EPEL-Next is not a complete rebuild of all the EPEL packages, but only those packages that need to be rebuilt to install on CentOS Stream. The EPEL-Next repo is meant to be layered on top of the regular EPEL repository.
Learn more about EPEL-Next on the following page:
* link:epel-about-next[ EPEL Next]
[[what_packages_and_versions_are_available_in_epel]]
== What packages and versions are available in EPEL?
@ -77,7 +92,8 @@ Alternately, you can browse the package set:
* EPEL 8:
https://download.fedoraproject.org/pub/epel/8/Everything/x86_64/[x86_64],
https://download.fedoraproject.org/pub/epel/8/Everything/s390x/[s390x],https://download.fedoraproject.org/pub/epel/8/Everything/ppc64le/[ppc64le],
https://download.fedoraproject.org/pub/epel/8/Everything/s390x/[s390x],
https://download.fedoraproject.org/pub/epel/8/Everything/ppc64le/[ppc64le],
https://download.fedoraproject.org/pub/epel/8/Everything/aarch64/[aarch64],
https://download.fedoraproject.org/pub/epel/8/Everything/SRPMS/[sources]
* EPEL 7: https://download.fedoraproject.org/pub/epel/7/x86_64/[x86_64],
@ -109,7 +125,7 @@ EPEL has an 'epel-release' package that includes gpg keys for package
signing and repository information. Installing this package for your
Enterprise Linux version should allow you to use normal tools such as
yum to install packages and their dependencies. By default the stable
EPEL repo is enabled, there is also a link:EPEL/testing['epel-testing'
EPEL repo is enabled, there is also a link:epel-testing['epel-testing'
repository] that contains packages that are not yet deemed stable.
* NOTE for RHN users|You need to also enable the *'optional*' repository
@ -166,7 +182,7 @@ great to also maintain add on packages for Enterprise Linux. Much of the
early need was driven by what Fedora infrastructure needed on the RHEL
machines that built and maintained Fedora. From there things have grown
to a large collection of varied packages. See
link:History_and_Philosophy_of_EPEL[our history and Philosophy page] for
link:epel-about-history-philosophy[our history and Philosophy page] for
more information.
[[how_can_i_contribute]]
@ -174,7 +190,7 @@ more information.
The EPEL SIG is always looking for interested folks to help out. We
always need package maintainers, qa/testers, bug triagers, marketing and
documentation writers. Please see our link:Joining_EPEL[ Joining EPEL]
documentation writers. Please see our link:epel-help[ Joining EPEL]
page for more information on how to join the SIG.
[[communicating_with_the_epel_sig]]