#257 Create compat conflicts exception
Merged 5 months ago by carlwgeorge. Opened 5 months ago by carlwgeorge.
carlwgeorge/epel compat-devel-conflicts  into  main

@@ -82,8 +82,9 @@ 

  === Does EPEL replace packages provided within Red Hat Enterprise Linux?

  

  No. EPEL is purely a complementary repository that provide add-on packages.

- EPEL will not conflict with any of the channels that it builds against. That

- is currently:

+ EPEL packages will not conflict with any of the channels that it builds against, with limited exceptions

+ (see xref:epel-policy.adoc#conflicts_in_compat_packages[conflicts in compat packages]).

+ Currently those channels are:

  

  * For EPEL7:

  ** rhel-7-server

@@ -310,11 +310,16 @@ 

  xref:epel-faq.adoc#does_epel_replace_packages_provided_within_red_hat_enterprise_linux[Per

  RHEL Release Package Conflict Channel Exclusions]

  

- * EPEL packages must never conflict with packages in RHEL. See above link

- for a complete list of channels per RHEL Release that EPEL does not conflict

- with.  This includes source package names due to the way that koji deals

- with packages from external repositories.

- * EPEL packages can conflict with packages in other RHEL channels.

+ * EPEL packages must not conflict with packages in the target base of RHEL.

+ See above link for a complete list of channels per RHEL Release that EPEL does not conflict with.

+ This includes source package names due to the way that koji deals with packages from external repositories.

+ * As an exception to the above rule,

+ devel packages in EPEL that are alternate versions of devel packages in RHEL (i.e. compat packages)

+ are allowed to conflict with each other.

+ See the section about

+ xref:epel-policy.adoc#conflicts_in_compat_packages[conflicts in compat packages]

+ for more details.

+ * EPEL packages can conflict with packages in other RHEL channels outside of the target base.

  * EPEL maintainers should be open to communication from RHEL maintainers

  and try and accommodate them by not shipping specific packages, or by

  adjusting the package in EPEL to better handle a conflicting package in
@@ -331,12 +336,14 @@ 

  [[conflicts_in_compat_packages]]

  == Conflicts in compat packages

  

- Due to the EPEL policy of maintaining backwards compatibility, EPEL has

- a greater need for forward compat packages than Fedora. When creating, a

- compat package, note that it is okay to set a Conflicts between them as

- noted in the xref:packaging-guidelines::Conflicts.adoc#_compat_package_conflicts[Conflicts

- Guidelines]. At this time, this is only allowed for packages overriding

- packages in EPEL, not in RHEL Base.

+ Due to the EPEL policy of maintaining backwards compatibility,

+ EPEL has a greater need for forward compat (i.e. newer alternate version) packages than Fedora.

+ There may also be cases where backwards compat (i.e. older alternate version) packages are needed.

+ When creating a compat package,

+ note that it is okay to set a Conflicts between them as noted in the

+ xref:packaging-guidelines::Conflicts.adoc#_compat_package_conflicts[Fedora Conflicts Guidelines].

+ 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

@@ -103,11 +103,10 @@ 

  to, https://docs.fedoraproject.org/en-US/quick-docs/fedora-and-red-hat-enterprise-linux/index.html[Red Hat Enterprise Linux] (RHEL),

  CentOS, Scientific Linux (SL), Oracle Linux (OL), AlmaLinux (AL) and Rocky Linux (RL).

  

- EPEL packages are usually based on their Fedora counterparts and will

- never conflict with or replace packages in the base Enterprise Linux

- distributions. EPEL uses much of the same infrastructure as Fedora,

- including buildsystem, Bugzilla instance, updates manager, mirror

- manager and more.

+ EPEL packages are usually based on their Fedora counterparts

+ and should not conflict with or replace packages in the base Enterprise Linux distributions.

+ EPEL uses much of the same infrastructure as Fedora,

+ including buildsystem, Bugzilla instance, updates manager, mirror manager and more.

  

  Learn more about EPEL in the following pages:

  

This seems reasonable, clearly written, and consistent with the Fedora policy.

I believe this is what we agreed upon in the Committee meeting. And I second what music said.

rebased onto e83d18c

5 months ago

I just noticed that the next sentence after the change in the FAQ was confusing, so I pushed a slight adjustment to clear it up.

-That is currently:
+Currently those channels are:

This looks ok to me. +1 here

Pull-Request has been merged by carlwgeorge

5 months ago