The Latest Fedora Debate: DNF Can Remove Systemd, RPM

[mufasa72]

Have you tried emerge -avuDNt world?

You forgot "--with-bdeps=y"

[lovenemesis]

RTFM

Not very polite but this entire whole flame war can be avoided if the original reporter can read:

http://akozumpl.github.io/dnf/cli_vs_yum.html

Simply put: dnf doesn't understand protected package now. Thus if a package has problematic deps, it may remove the entire system.

No surprise, not worth the flame war.

BTW yum introduce multiple download package in 3.4.X for a while. It's not something new in DNF.

[vadix]

Pacman could use parallell downloads.

Thank you. This is the first time ive ever seen somebody else suggest this. You could download packages from multiple repos at once. After all, most of pacman's time is spent downloading. My friend did a whole arch install (with xorg) on an SSD in about 10 seconds, while the packages took a few minutes to download.

[Nobu]

Tried in a chroot, rm did well to protect my root. lol
Also, was able to remove everything once I bypassed the protection (bash was even still working fine), but I imagine it wouldn't go so well if I wasn't in a chroot.

Edit: I imagine the only reason pacman doesn't implement parallel downloads is because of the increase in server load that would cause. Or maybe they just think it'd make pacman too complex. Either way, it works fine for me, though I wouldn't mind if they did implement it.

[strcat]

Tried in a chroot, rm did well to protect my root. lol
Also, was able to remove everything once I bypassed the protection (bash was even still working fine), but I imagine it wouldn't go so well if I wasn't in a chroot.

Edit: I imagine the only reason pacman doesn't implement parallel downloads is because of the increase in server load that would cause. Or maybe they just think it'd make pacman too complex. Either way, it works fine for me, though I wouldn't mind if they did implement it.

A common argument raised against doing it is that the output would be incomprehensible. Since there are plenty of mirrors providing 10-20MB/s throughout, it's unlikely to receive much attention. If the bottleneck is your connection, parallel downloads aren't going to help.

[Anvil]

i myself just dont think DNF is ready to replace YUM as default. not till F23 atleast. , if its still goes on as default in F22 i'll switch over to opensuse

[DrYak]

Someone enlighten me, when they say it's fast and modern, what exactly does that mean? I've never ran 'sudo pacman -Syu' or 'sudo apt-get upgrade' and thought 'boy, is this upgrade a slow piece of crap I wish they'd speed it up'.

To resolve dependencies, old-generation package manager like "yum" use bits of cobbled together heuristic and a few hacks.
Modern package manager like suse's "zypper" and the upcoming "dnf" (both built arround suse's "libsolver") built mathematically sound and provably complete approach like SAT-solvers.

So, if you ask for an upgrade and yum upgrades only a few package, everything works, and as you say the bottleneck is the download.

BUT if you change the URLs of all your repositories (the base one and all the various 3rd parties) to the newest distribution release (i.e.: requesting a full-OS upgrade to the latest version) and require a "yum upgrade" that's going to take ages. Yum will need to compute the dependencies of thousands of packages. And will probably barf a few time on the road and finish with unresolvable dependencies.

Whereas a SAT-solver simply rescans the dependencies network, *as usual*. The only difference being that it will take a few seconds instead of being instantaneous (the final solution of the network is a bit further from the initial network state than with simple upgrades) but otherwise it's just work as usual.

In fact, that approach (change all the URLs then run a normal upgrade) is a standard procedure to upgrade the system.

(Compare with: old distributions (old versions of Debian) did require you to remove all 3rd parties, and only attempt upgrade against the base repository, using a speical "dist-upgrade" command instead)

The user requested the removal of pcre. Thus, the package manager computed the necessary operations to accomplish that request. Granted, it's not a good experience for a user who happens to be completely clueless about the underlying system and blindly okays everything.

I know dpkg handles this problem quite effortlessly with the "essential" priority class, but I am not sure if RPM has anything similar that could be used.

Suse use "pattern packages" (normal RPMs, used for special purpose)

Yum won't remove systemd/glibc/rpm 'cause they are hardcoded.
Such preferences can be hardcoded into DNF as well. I guess it will take just a few lines of code to actually implement this limitation against the stupid.

They should be hardcoded, but they should not be hardcoded *in the package manager*.
This kind of stuff should go inside the distribution it-self.
For example, suse does it with a bunch of special "Pattern" package that describe general use (it's similar concept to gentoo's virtual package). These "patterns" pull-in a bunch of necessary package without which a system would not be usable for a given usage pattern. When the distribution upgrades, these "patterns" get upgraded too and might pull in a different set of requirement.
(In the example of the current "DNF vs. Kernel and glibc", there should be a "basic bootable system" patterns that requires on package that provides "kernel" and that require one the various packages (Glibc, ucLibc, etc.) that provide "c library". The badly broken "prce" package would have resulted into the solver complaining that it conflict dependencies of "basic bootable system")

This system works actually pretty well: I've been through some rather deep radical upgrades flawlessly - like switching away from HAL, like switching to systemd, etc.
All handled with the standard "change URLs, run upgrade" approach.
(This would have been impossible with hardcoded dependencies in the manager, because one thing critical for one version (sysvinit) would be deprecated by something new (systemd). Or at least it would have required additionnal heuristic hacks to be able to handle a system upgrade).

Straight from the openSUSE Wiki... http://en.opensuse.org/openSUSE:Libzypp_satsolver

Since the solver treats every package alike, these rules have some major and sometimes unexpected implications. A broken dependency might result in removal of lots of packages - the resulting system is still consistent by highly unusable.

Yet, I haven't had a breakage on suse, although I'm doing the "change URLs, run upgrade" approach for quite several suse releases.

The thing is: Yes, indeed, solver treat all package alike (there is no "essential" priority class in zypper). But thanks to the "patterns" package there are still sane requirement somewhere. And due to the way SAT-solver work internally, the package manager is able to output a coherent message.
The removal of "prce" would trigger a clear warning that is breaks the dependencies of "Graphical Desktop" pattern.

For that to work:
- it requires that the package manager could work through huge dependencies tangled thread-balls. That's why SAT-solver are used in modern managers.
- it requires also that the distro repository gets its dependencies correctly re-organised. Everything that was formelly hard-coded into yum (DO NOT REMOVE: kernel, libc, etc.) should now be formelly described into various dependencies (dependencies of packages, and additional helpers like "pattern").

That requires some work. It will take some time, but by the time Fedora 22 is declared stable (or even the corresponding RedHat/CentOS) - such bugs should be ironed out.

Simply put: dnf doesn't understand protected package now. Thus if a package has problematic deps, it may remove the entire system.

...but the package manager shhould be able to clearly state that the entire system is getting removed.

(That's what "pattern" packages are for. Given the correct setup, it should give a coherent message like "this breaks the dependency of 'stable bootable system' possible solution: A. keep prce and 'stable bootable system' installed. B. mark 'stable bootable system' as unrequired and remove (list of nearly everything)' )

Also note: PRCE isn't broken per-se. It provides regular expression support. That's used for nearly everything: by several core utilities (sed, grep, awk, perl, etc... all use regular expressions) and also a dependency of several desktop interface libraries (Qt, Gtk, ... lots of them provide reg-exp).
By removing PRCE, you remove also a huge chunk of command-line utilities, and you remove a lots of graphical utilities. You're left with a system which only has the few tools that don't do reg-exp. That's a technically correct behaviour.
Again the problem isn't that PRCE should not be allowed to be removed (hard-coded stuff is a bad idea) , it isn't also that half the system is uninstalled (half of the system DOES use reg-exp or depends on tools/libraries which have reg-exp support).
The problem is that DNF should have a way to know that the removed packages might have been desirable to the user because they fit a certain usage pattern that the user wants.

Old yum would not reach that point, because there are simply way to many dependencies to handle, some ending up breaking some heuristic somewhere. Yum would probably refuse uninstalling PRCE either because of "unresolvable dependency" or "unauthorised removal of hard-coded package perl".

SAT-solvers are good at dependencies solving and thus the prenvention should not rely on the package manager blocking, it should be done in another way.

[rdnetto]

Touche! I have actually, but I've never used Gentoo for any length of time, I would install it, get frustrated and then try something else. I understand use flags and I totally get why someone would want them, but I never found them to be anything other than a pain to deal with. I like the idea of Gentoo, I guess it's just not for me.

Have you tried using Sabayon? It's a Gentoo derivative that uses binary packages for most things, but let's you use portage when you need it. This means that you only need to worry about USE flags when the defaults leave something out (i.e. almost never).
I use it as my main distro, and it works quite well.

[rohcQaH]

about good old rm -rf / :

The protection is not about the idiot user who would run it (you want it, you get it!), nor about the fact that the command couldn't complete once parts of your system disappear (it can!). It's a protection against scripts doing something like:

CACHEDIR=/var/cache/....
...
rm -rf $CACHEDIR/

so if $CACHEDIR gets unset for some reason or another, the command turns into rm -rf /, which is certainly not what was intended.


So if someone wants DNF to protect against broken packages, the rm -rf / protection can apply as precedent. It's not a precedend to guard against user error; whoever thinks that doing dnr remove pcre should be safe needs another argument.

It's just an update command for Gentoo, which takes a fair amount of time per update needed, as builds everything from source. If you add -e then it rebuilds your entire system from source, from the kernel up, which takes a while.

Nope. It reinstalls / recompiles every single package, but the kernel packages have no actual compilation step. They just extract the sources to /usr/src/. You need to compile and install the kernel manually.

I've never used Gentoo for any length of time, I would install it, get frustrated and then try something else. I understand use flags and I totally get why someone would want them, but I never found them to be anything other than a pain to deal with. I like the idea of Gentoo, I guess it's just not for me.

Maintaining a gentoo install is indeed time consuming, and you shouldn't start an upgrade unless you have some free time for disaster recovery, just in case. The upside is that you can easily add or remove unwanted features (USE="-pulseaudio +systemd -gnome +kde"), you automatically have development headers for *all* packages, you can trivially apply a patch to a system package and recompile it, and you can setup your system to store debugging symbols for everything, generating complete and useful backtraces whenever something hits the fan. You also learn quite a bit about your system in the process.

As a developer, I like it. For a user, I wouldn't recommend it.

[blackiwid]

i myself just dont think DNF is ready to replace YUM as default. not till F23 atleast. , if its still goes on as default in F22 i'll switch over to opensuse

lol really? I dont get why people are so extremly into package-managers. What do u do with that tools instlaling 1000 new packages each day? The normal person makes 1 upgrade every day or week, and maybe 2-3 installs every week.

And then u want to switch to what opensuse, hmm what is DNF a port of opensuses package-manger-backend to fedora. So you more or less switch from DNF to DNF.

I just dont understand that mindsets, last thread I read someone stays on debian because yum is to slow for him. Isnt it much more important if you have 1-2 year old stuff or extremly recent stuff on your pc (both can be good for different people) than how fast that upgrade-tool is or if it protects u from pressing blindly yes to every bad install-proposal.

DNF is now soon be new default, so I guess u can install yum a while instead too? Like in debian since 100 years aptitude "replaced" apt-get but still everybody uses only apt-get.