Depends on your definition of reliability I guess.
If I have two scripts running in parallel which both wants to install packages, using apt will cause one of the scripts to fail, because apt is already locked.
dnf however will be just fine, because instead of failing it will just queue and wait for the lock to be released.
There's small things like that all over which to me, as an end user, makes relying on dnf feel much safer.
> Depends on your definition of reliability I guess
No, not at all. Not doing the elementary work to design the package manager in a way that it will keep the system in a consistent state as it is reasonably possible is unreliable. On top of that, if the developers of the said software are ignoring the issue, denying it is their responsibility and tell people to use a different program instead, I will personally not touch it with a 10 foot pole.
Refusing to run when a concurrent copy is already running on the other hand, is just a comfort issue.
> makes relying on dnf feel much safer
So you are OK with ignoring a real reliability issue and a trivial UX behavior is enough for creating an illusion of safety?
Check the thread I've posted, Fedora developers are more than happy to recommend not using DNF and using offline updates thing instead.
Now try running multiple instances of "offline update" thingy and see how far it goes in your pet scenario ;)
> so you are OK with ignoring a real reliability issue and a trivial UX behavior
Reliability has many dimensions.
If I can't trust that the package manager handles all the issues you can encounter when managing packages, I cannot trust any component which interacts with the package manager to be reliable either.
dnf does a lot of right things(tm) which apt doesn't, which means I can trust that scripts I write to work with the package manager will work reliably.
Apt outsources approximately 2 out of 3 failure-modes to its users meaning every automated attempt to interact with it, is bound to fail on stupid shit it shouldn't.
And then you can't rely on apt. Apt is not reliable.
To me it seems like a misinformed version of "KISS"/"YAGNI", because you do need a package manager to handle and abstract all those things. That's what it's for.
OK, now I understand what you mean by reliability and I appreciate that. Thanks for explaining it.
I'm just not comfortable you claiming it is more reliable than apt because then some people will think it is a package manager with minimal amount of importance was attached to its design so that it won't leave the users system in an inconsistent state even in most easily correctable scenarios when that's actually not the case.
You can not safely install two packages concurrently. apt-get's choice to refuse to run is a much simpler solution that better adheres to the KISS principal and is therefore less prone to error. You could queue apt installs of you really wanted to with a simple for loop on the command line.
But dnf doesn't break your script or force every script in the universe to reimplement the same polling loop, because it's implemented one place, centrally, so everyone else can forget this problem even exists.
dnf clearly does the right thing here, while apt causes breakage. I don't see how anyone can argue anything else.
It's not KISS if everyone else has to work around your shortcomings. Then it's just inadequacy.
If I have two scripts running in parallel which both wants to install packages, using apt will cause one of the scripts to fail, because apt is already locked.
dnf however will be just fine, because instead of failing it will just queue and wait for the lock to be released.
There's small things like that all over which to me, as an end user, makes relying on dnf feel much safer.