PAGING LENNART POETTERING
Yum/dnf haven't been merged into systemd yet, please merge
Yum is dead, long live DNF
91–100 of 128 posts
Re: Yum is dead, long live DNF
#92So, like, what is a package manager and what does it need to do? All the distros have one. All the lanaguages have one. Why do we have so many of these things and is all the complexity necessary? All our configuration management tools try to abstract the differences. The list goes on on and with these things. As I start down the path of doing more and more operations/systems administration I find myself asking the qu…
Excellent questions. I bet it's largely because lots of open-source people want things exactly their way.
Re: Yum is dead, long live DNF
#93Earlier quoted context omitted.
The portage ebuild system for describing package dependencies and build procedures is awesome. The portage program for solving dependencies and building packages is mediocre at best—it's slow and too prone to not finding a solution even when the constraints of source compatibility are looser than binary compatibility. The gentoo portage repository of packages is clearly understaffed and orphaned packages are all too…
Correct, the all-around best choice is Exherbo's package management. It is extremely similar to Gentoo (after all, many of us used to work on Gentoo), but I'd like to think it has fixed all the problems Gentoo had. Portage is not used.
There's no way that Exherbo's package repos are anywhere near as well maintained and broad as the distros that people have actually heard of. There's no silver bullet for that problem; the only solution is manpower that they don't have.
Re: Yum is dead, long live DNF
#94Earlier quoted context omitted.
> Also, "dnf" is not at all awesome to say out loud, while "yum" is among the most awesome commands to say out loud. Indeed, to me, saying "dnf" out loud suggests "did not finish," which is the opposite of what you want from a package repository tool!
Well, they eventually did finish Duke Nukem: Forever, right?
Well, they released it anyway. :P
Re: Yum is dead, long live DNF
#95Earlier quoted context omitted.
Correct, the all-around best choice is Exherbo's package management. It is extremely similar to Gentoo (after all, many of us used to work on Gentoo), but I'd like to think it has fixed all the problems Gentoo had. Portage is not used.
There's no way that Exherbo's package repos are anywhere near as well maintained and broad as the distros that people have actually heard of. There's no silver bullet for that problem; the only solution is manpower that they don't have.
Exherbo's package repos are incredibly well-maintained. What is provided generally always works and things are kept very much up to date (KDE/gnome/chrome/firefox updates within 24 hours usually). Lack of public awareness doesn't always mean the system isn't as well maintained as a system like gentoo (which often breaks!)
The broadness of the system isn't quite as vast as many distributions but running a desktop / dev workstation I have never encountered a package not available that I needed.
Re: Yum is dead, long live DNF
#96Out of curiosity, why not fix something if broken? Why is there is always a half baked alternative that has a different set of problems. Instead of replacing what is perceived broken you can just fix it also keeping the good parts. I have several systems deeply vested in in the yum/rpm ecosystem and I see very little chance that a new package manager is going to offer that much new features that I need while keeping…
It's the CADT model of software development, as usual.
Re: Yum is dead, long live DNF
#97Earlier quoted context omitted.
Red Hat (the company) and RPM (the format) predate Debian, although only by a few months. Also RPM is a much better format than deb, and that's speaking as someone who regularly makes packages using both. I would also say that dnf and zypper are better package managers than apt, in as much as they are faster and easier to automate. Compare the code here: https://github.com/libguestfs/libguestfs/blob/1.29.43/custom...
What? how is this better? what all of this is is apt making users say yes to everything such as config changes. I'm totally fine with that. Sure it's an extra line or 2 when automating, but I don't see it as bad.
I don't know about you, but I'd rather use the tool that I don't have to hack the training wheels off of first when I'm trying to update 100,000 machines to mitigate a critical security issue.
Re: Yum is dead, long live DNF
#98I still think pacman is far superior to yum or apt-get
As someone who has rewritten pacman for fun, it's not great. The tool itself works well, and quickly, but the package format is... interesting. Provides seem like a bad afterthought, and package signing being opt out and constantly breaking is interesting, at best.
Re: Yum is dead, long live DNF
#99Earlier quoted context omitted.
You can also use `aptitude`, available on both Debian and Ubuntu. It addresses your complaints and it's the first package I install.
Since apt-1.0 (basically, since jessie), there's also apt(8), which integrates (most of) apt-get and apt-cache.
Thank you! I had no idea it existed
Re: Yum is dead, long live DNF
#100Serious question, because I am admittedly ignorant to the plusses and minuses of the different package managers. If you're going to swap out: why not switch to apt? What does apt lack that DNF is going to provide? This seems like one of those low hanging fruit where standardization across distributions would make sense.
Everyone should switch to Portage. It's like a superset of every package manager.
If we're going to be one-upping each other, then let me suggest Nix, a superset of Portage.
It has many of the strengths of Portage, and even go beyond (it builds from source, and users may configure package dependencies, like USE flags on steroids -- its declarative language used to write packages is also used to configure them, so you can do more than just passing flags to a package). But it offers a substantial advantage, because builds are deterministic. The set of installed software (with all needed configuration) is determined from a config file (or many), and from this it's always possible build the same system.
This means that upgrading always end up in the same state as installing from scratch. This also mean that common packages can be cached as binaries, without risk of breakage - it only downloads a binary package when building from source would build exactly the same binary.
Nix also feature atomic upgrades and rollbacks: it only touches the running environment as the very last step of the upgrade (setting up a symlink), and stores the previous versions of packages until garbage collected, so an upgrade stopped in the middle can't break your system (the exception here being kernel upgrades). Indeed, if you interrupt an upgrade or install at any stage, just issue the command again. (also, this architecture makes it incredibly concurrent)
NixOS is a distro that uses Nix. It can provide a GRUB menu to boot previous versions of the system. When you upgrade, you can have it affect running system or only upgrade after a reboot. Either way, when you reboot GRUB will give the option to also boot the system you was using before the upgrade. On a technical level, Nix works a bit like a git repository: each package is addressed by the hash of its derivation (that says how to build it, and all its dependencies), and if more than one system version uses the same package it gets stored only once.
Coupling NixOS with Nixops, a deployment tool; and Disnix, that does service-oriented deployments (like Docker), they can help build more repeatable systems for production servers too.
Some links: