EPEL, ELN and Fedora packaging requirements

Project Discussion
1

Does everything in EPEL and ELN meet fedora packaging requirements?

Would your package be easier to build if you could select specific releases of dependencies?
Would your package be easier to build if you could select specific releases of dependencies?
Would your package be easier to build if you could select specific releases of dependencies?
2

It must. EPEL is all backports from Fedora, and ELN is all rebuilds of Fedora Rawhide.

3 Likes
3

What? There are no EPEL-only repos? Is the exception for EPEL-only repos vestigal? I see them in the dist-git.. things with EPEL-only branches and no rawhide branch. And I see documented exception policy about how they are allowed to be used.

4

There are, and it’s not.

The purpose of creating epel-only packages is usually to avoid package name collisions with RHEL or to provide alternative versions of packages that are in Fedora and / or RHEL.

In both cases, the original package must have gone through package review for Fedora.

1 Like
5

must they? Is there no example of an epel-only package that didn’t go through fedora review

Can you walk me through the review process that happens when an epel-only branch is spun up to ensure that its contents have gone through fedora review?

So lets break this down…
There are 2 types of things:
type 1:
For existing components that have an existing rawhide btanch… We’re basically talking about adding additional branches that track upstream sources. A subproject that was a allowed to use those branches could have some policy with regard to coordinating spec file changes strictly necessary with rawhide for building the upstream source. Is this an area of concern? Is the fact that the rawhide branch exists and went through review provide enough review to establish some baseline conformance?

type 2:
Things that aren’t buildable in rawhide because of the dependency chain available inside rawhide as a integrated platform of dependency can’t be met in a self consitent manner. These would obviously need a review process to ensure that the goals of packaging requirements were met. Licensing, the prohibition of shipping prebuilt binaries. That review would need to be done by the participants of the subproject who have an interest in bringing this subproject to life. This doesn’t get off the ground as a viable subproject if there aren’t a subset of contributors who are already trusted to do package reviews who are willing to this sort of review. I think that should be obvious.

6

Things in EPEL meet the fedora packaging requirements of the time that the branch were made. (so EPEL-6 would generally be Fedora 12->17, EPEL-7 would be 18->27, etc) In many cases packages are updated to meet newer requirements because not doing so means the package no longer builds in koji. EPEL only packages also must go through new package review like they were going into Fedora rawhide.

ELN is also the same way. It is actually part of the selling point of Fedora->ELN->CentOS Stream->RHEL->various certifications.

7

Someone replied to a topic you are Watching.

Jef Spaleta https://discussion.fedoraproject.org/u/jspaleta jspaleta
Fedora Project Leader
September 30

Fabio Valentini:
In both cases, the original package must have gone through package review for Fedora.

must they? Is there no example of an epel-only package that didn’t go
through fedora review

As far as I know there have not been any from EPEL-5 to EPEL-8. Even things which were ‘oh take this from RHEL and compile it on Power since RHEL doesn’t’ had to go through a review.

Can you walk me through the review process that happens when an
epel-only branch is spun up to ensure that its contents have gone
through fedora review?

From EPEL-5 → EPEL-9

You have to follow the new-package process but say that this is EPEL only. When the package is reviewed and approved you must put a DEAD.PACKAGE in rawhide.

I do not know lately.

I thought that Gordons’ original post had that new specs would be built via automated tools (or am I confusing this with something rbean wanted 3-4 years ago or a different proposal on this in the 2010’s?) Adding in steps to do automated reviews with ‘fix these things before we can build’ was something I remember from some proposal.

Would your package be easier to build if you could select specific releases of dependencies?
Would your package be easier to build if you could select specific releases of dependencies?
8

Even the rare EPEL-only package (which are usually compat packages from Fedora and whatnot) must follow the Fedora Packaging Guidelines. FESCo governs EPEL and ELN just like Fedora too.

9

I was asked to move the posts about EPEL & ELN into a separate topic → I have no time to read through all the posts but only skimmed quickly, so if I missed a post, let me/us know.

Also, since we have much more Trust Level 4 (TL4) users than moderators: users with TL2+ (or TL3+?) should be able to call @trust_level_4 along with @moderators to get help more quickly → TL4 can split & merge (topics) and move (posts) as well :classic_smiley:

(I wonder if it makes sense to add the possibility to split/merge/move to the FESCo group :confused: If you think that’s useful, create a topic in our forge, just in case.)

Feel free to adjust the title or ask if I/we should do so.

10

If there are, so what? Are you trying to establish some sort of precedence for EPEL outside of Fedora?

EPEL is part of Fedora, at least last time I checked. And so its packaging policy applies unless detailed specifically otherwise by Fedora’s EPEL packaging policy. “Branches” lead aside. Obviously :wink: