Red Hat Pushing DNF 5 Into Development For Improving The Package Manager

[andyprough]

Like more or less every other package managers ever.

I haven't seen this behavior in many years from any package manager. I just showed that pacman will refuse to do it, I know with absolute certainty that apt and zypper will refuse to do it. Are you using a force option or how are you managing to demolish your poor abused systems in this manner?

[skeevy420]

I see...

I don't use Fedora but the SilverBlue caught my attention, when eventually they will fix all the mess with their repos I may give it a chance over a just a simple virtual installation. Everything in that project is smart and clever!

I'm really liking it. It's different, but, for me anyways, learning the rest of the Fedora/RHEL ecosystem is what's hard about it. rpm-ostree, ostree, and basic system administration is pretty straight forward and all the tools have good help with the help flags and decent enough documentation.

I've been an Arch/Manjaro user for the past decade and I haven't used anything from this family since....well....Fedora didn't exist and Red Hat was still free. If you're more comfortable with RPMs you'll probably have an easier adjustment period.

Small projects that I could finish within a day are head-scratchers for me here. Just takes time to learn the tools. Like, yesterday I learned WTF a Roji was.

[vb_linux]

It's better than Java, javascript, Perl and Ruby.

Javascript, Ruby, Perl ---Yes.

Java --- No in terms of performance, yes in terms of ease of use. But any enterprise system should still prefer Java over Python.

[andyprough]

No he isn't. Dnf history isn't just a history log. It can undo, redo any transaction and has additional metadata including whether that transaction is user initiated etc

https://dnf.readthedocs.io/en/latest...-command-label

It is quite handy

This is all available under pacman or with its tools. Just because tools have been rolled directly into dnf doesn't change the actual behavior. End user doesn't give a crap if the package manager or its tools are doing the work.

[skeevy420]

This is all available under pacman or with its tools. Just because tools have been rolled directly into dnf doesn't change the actual behavior. End user doesn't give a crap if the package manager or its tools are doing the work.

Until the tool you use quits being maintained by the community member who maintained it.

It's like thinking one can rely on a random AUR package for Pacman hooks for ZFS backup and restoration. A bunch of those have come and gone already.

[Britoid]

No it won't. I just typed in sudo pacman -R glibc, and it responded with a massive list of errors due to dependencies that would be broken if glibc was removed, and refused to do it.

It will if you tell it to ignore dependencies. dnf as far as I'm aware, has no similar mode.

Pacman will give you far more freedom to do what you want with your system than dnf will. They're targetted at very different types of systems, which goes back to the original complement about replacing everything with pacman.

[ptrwis]

I wouldn't use the "dumping ground" term for Python, but yeah, it's basically taking over anything that is too complex for a shell script and not performance-critical enough to be compiled.

Things don't need to be performance-critical to be compiled, compilation is also a process of verifying the code, and it wouldn't even help because these interpreted languages don't have solid type checking. But what's annoying from user's perspective is every VM-ed or interpreted language is a huge third-party thing with it's own gazillion of dependencies which later needs to be maintained, even if it's just about updating it. On a small server system I'm forced to install Python only(?) because of dnf and firewalld.

[andyprough]

It will if you tell it to ignore dependencies. dnf as far as I'm aware, has no similar mode.

Pacman will give you far more freedom to do what you want with your system than dnf will.

You would just use rpm commands if you wanted to take a chainsaw to your rpm-based system like that. You are talking about extreme and odd behavior on the part of the user. Just because Arch doesn't have another entire underlying package management system you can use to screw it up doesn't mean there is an actual difference.

[starshipeleven]

I haven't seen this behavior in many years from any package manager.

 sudo zypper remove glibc
[sudo] password for root:
Reading installed packages...
Resolving package dependencies...

Problem: This request will break your system!
  conflicting requests

 Solution 1: ignore the warning of a broken system (requires:glibc)
 Solution 2: keep glibc-2.31-2.1.x86_64

Choose from above solutions by number or cancel [1/2/c/d/?] (c):

I mean, I get a warning, but I'm still technically allowed to ignore it and pull through, nuking the system. I've used this ability to ignore packaging requirements a few times to deal with broken (third party) packages in the past.

And this is better than what apt does, it will not give warnings or anything, just dump a huge list of stuff to "delete" and ask to confirm. And does not allow you to install ignoring package requirements either, you must do stuff manually.

[Britoid]

You would just use rpm commands if you wanted to take a chainsaw to your rpm-based system like that. You are talking about extreme and odd behavior on the part of the user. Just because Arch doesn't have another entire underlying package management system you can use to screw it up doesn't mean there is an actual difference.

Well yes, you can also mess it up by just removing the files yourself.

But we're talking about dnf vs pacman here.