Announcement

Collapse
No announcement yet.

Fedora 36 Establishing ELN-Extras, Fedora 37 To Retire ARMv7

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Fedora 36 Establishing ELN-Extras, Fedora 37 To Retire ARMv7

    Phoronix: Fedora 36 Establishing ELN-Extras, Fedora 37 To Retire ARMv7

    The Fedora Engineering and Steering Committee (FESCo) has signed off on more feature work for the current Fedora 36 cycle as well as Fedora 37 due out toward the end of next year...

    https://www.phoronix.com/scan.php?pa...tras-F37-ARMv7

  • #2
    So is this about adding things to Fedora like Gluster that it didn't have before, or is this about removing things that were in Fedora and moving them into an EPEL type repo or worse into a "channel"?

    Comment


    • #3
      Originally posted by MadeUpName View Post
      So is this about adding things to Fedora like Gluster that it didn't have before, or is this about removing things that were in Fedora and moving them into an EPEL type repo or worse into a "channel"?
      Not sure what you mean since Fedora has had gluster for years. If you read the linked change, ELN is a branch of Fedora, just built differently. It doesn't have any exclusive packages.

      Comment


      • #4
        Originally posted by MadeUpName View Post
        So is this about adding things to Fedora like Gluster that it didn't have before, or is this about removing things that were in Fedora and moving them into an EPEL type repo or worse into a "channel"?
        The primary value for adding ELN-Extras to the ELN process (and ELN is about Enterprise Linux Next, or, to make it real, ELN will eventually be the basis for a EL10 fork, which is probably over two years away) will be to make it far easier for some to "prep" their existing EPEL packages. Today, if you are a packager who wants to build a EPEL package, one has to first wait for the stream to be released (which is close to the ELn release), and only then start to ask all those packagers who *your* package depends on to branch and port their package (or you have to do your own builds, which can easily turn into dependency heck involving many dozen of other packages). This can (usually does) mean that when ELx is released, a (mostly) complete EPELx lags behind. Having a place where (at least some) of the packages you will need to have built are already available may make it possible that EPELx is available sooner.

        Comment

        Working...
        X