DNF5 Isn't Ready For Fedora 39 - Now Delayed To Fedora 41

[Eudyptula]

The concern is that with EL 10 expected to branch with F40 as the base that things could get complicated if dnf5 turns out to not truly be EL ready (including all the ancillary things that their enterprise customers have come to expect/demand) as if dnf5 does not land until F40 there may simply not have been sufficient testing to know about potential issues before that EL branching. There are ways to address at least some of that concern, but for now the dnf5 change for F39 is being reverted, and the Fedora project will have to see where the dnf5 team is at some future point as they continue their work.

I realize that Fedora is meant to be tested before RHEL derives from it, but DNF is already tested, right? So would it be so bad to enable DNF5 in Fedora 40 and RHEL can still opt out of DNF5 if it isn't ready when the time comes? And what better way to test DNF5?

DNF5 wont make it for EL10 as it just aint Ready, it lacks what DNF4 has + the Developers are getting to thje point of getting Burnt out so it made sense to postpone it to F41, it still could make it for F40

Burnout is real and shouldn't be brushed under the carpet. Neither at work or private. :/

So while it's disappointing news I'd rather it be postponed than them becoming burnt out. Perhaps it raises the question whether Red Hat should put more resources into it?

we did, and will. they coexist in F38 and they will in F39 too. the debate boils down to which one gets to be `/usr/bin/dnf`. with this Change reverted, for F39, `/usr/bin/dnf` will be DNF 4 and DNF 5 will be `/usr/bin/dnf5`, same as in F38 (and DNF 5 probably won't be installed by default, you'll have to do `dnf install dnf5`).

Many people report no issues with DNF5 fully enabled on their systems. Is it a matter of use-case where they just aren't stepping where fundamental floorboards are missing?

There might be good reasons for DNF5 not being enabled by default with no strings attached to the next RHEL release, of which I would be ignorant. Though, I don't see how it being in Fedora 40 have to necessarily force it on RHEL if it turns out that it is indeed not ready in time when that time comes. After all, it'll be continued to be developed after the Fedora 40 release.

Is there any reason I shouldn't fully move to DNF5 on my system when Fedora 40 gets out? I've been eagerly excited about DNF5 for a long time now.

Every day I'm glad I left Fedora. DNF is horrible, and despite YouTuber hype, DNF5 isn't really that much better. I put up with it for too long, only after I switched I realised how much happier I am with a faster package manager even if I'm not constantly in/unin/reinstalling things every day. Never again having to deal with RPM Fusion and its packages constantly falling behind Fedora's and breaking shit is a nice bonus too

It's funny, because I'm using Fedora because of DNF. Yes, the slow one.

Why? Because its outputs are much better presented and the commands are sanely intuitive. It's nice to use. Preferably I'd like to see a table with current version and the proposed version to upgrade (in the same line). The current output is decent and certainly better than others, but still lacking in my opinion. I don't remember if this was improved with DNF5.

I agree that DNF is painfully slow, but DNF5 fixes that. What exactly is it that you think DNF5 is not much better at? Its performance improvements surely aren't exaggerated, so it must be something else you don't like.

Dnf is basically a piece of shit technology compared to the speed of alpine/arch package managers. Just try them. It's pretty obvious the fedora developers have no idea how good the competition is.

Well, speed is the primary purpose of DNF5 and the difference is night and day to the point where it seems to be comparable to other fast alternatives.

Saying that DNF is bad, period, because of this one flaw is not really fair. I think it's more nuanced, but if your opinion is that DNF is garbage simply because of its current performance, that's fine.

But since performance is the only gripe you seem to have with it, DNF5 should not be "piece of shit technology" according to your criteria. Do you agree with this?

[mether]

fair enough. I meant to say it's not the full testing of rhel point releases, which I suspect is true.

RHEL point releases are directly branches off CentOS stream and CentOS stream is upstream for it, so it should closely track the testing efforts.

honestly in looking into centos, I don't even see the point of it existing, it's basically as closed development as rhel is

It is far more open with CentOS stream since unlike before all the changes are published as development happen instead of only after the releases are made. This is CentOS stream has participation from other large organizations.

[fitzie]

Multiple Red Hat folks involved with CentOS Stream have pointed out that Red Hat QE does sign off on updates to stream. For example,

fair enough. I meant to say it's not the full testing of rhel point releases, which I suspect is true. honestly in looking into centos, I don't even see the point of it existing, it's basically as closed development as rhel is. redhat should call it free rhel free edition. that would end the people saying rhel isn't free.

[edit.. or maybe call it rhel unlimited]

[mether]

can you find one documentation link on centos.org that backs up this statement?

Multiple Red Hat folks involved with CentOS Stream have pointed out that Red Hat QE does sign off on updates to stream. For example,

In CentOS Stream however, all updates are pushed as soon as they are signed off by Red Hat Quality Assurance department

[fitzie]

Where did you get the impression there's no pre-QA? Red Hat QE tests every change before it becomes available in CentOS Stream (as binary packages).

can you find one documentation link on centos.org that backs up this statement?

[nado]

Will see how Fedora fares over the next few releases. A return to Debian may be in the cards

[mxan]

Some will deduce that but piss-poor job such tweeting is, for others (great majority?) will go off of it on tirades about RedHat - as many comments there already suggest.

Red Hat employees just seem unable to communicate. So many problems could so easily be avoided if they knew how to communicate properly, lol

[avis]

I've had exactly zero problems with RPM/DNF in Fedora/Fedora Core over the past two decades but I have some packages required for multimedia support:

dnf list installed | egrep -v "@fedora|@updates"
egrep: warning: egrep is obsolescent; using grep -E
Installed Packages
VirtualBox-7.0.x86_64                      7.0.10_158379_fedora36-1           @System      
faad2-devel.x86_64                         1:2.10.1-1.fc38                    @@commandline
faad2-libs.x86_64                          1:2.10.1-1.fc38                    @@commandline
fdk-aac.x86_64                             2.0.2-5.fc38                       @@commandline
fdk-aac-devel.x86_64                       2.0.2-5.fc38                       @@commandline
google-chrome-stable.x86_64                115.0.5790.102-1                   @google-chrome

Along with mpv, ffmpeg, x264 and x265 compiled manually from sources and installed into /usr/local.

Everything works fine.

[lejeczek]

CentOS Linux is being eliminated, but CentOS Stream, which is basically the same thing is not. Centos Stream, is basically is basically like a stable linux distro but with updates that don't have pre-qa (like updates-testing on fedora).

Some will deduce that but piss-poor job such tweeting is, for others (great majority?) will go off of it on tirades about RedHat - as many comments there already suggest.

[MrCooper]

CentOS Linux is being eliminated, but CentOS Stream, which is basically the same thing is not. Centos Stream, is basically is basically like a stable linux distro but with updates that don't have pre-qa [...].

Where did you get the impression there's no pre-QA? Red Hat QE tests every change before it becomes available in CentOS Stream (as binary packages).