5 ms·
FWIW, Fedora these days use dnf, which uses libsolv under the hood. https://github.com/rpm-software-management/dnf https://github.com/rpm-software-management/d
by mook 4y ago
FWIW, Fedora these days use dnf, which uses libsolv under the hood.
https://github.com/rpm-software-management/dnf https://github.com/rpm-software-management/dnf
https://docs.fedoraproject.org/en-US/quick-docs/dnf/ https://docs.fedoraproject.org/en-US/quick-docs/dnf/
- pxc 4y agodnf has copied zypper's other innovations as well, like vendor change. It's also fully usable on openSUSE, as a replacement for zypper, if you so desire. :) dnf and zypper are the best of the 'old school' package managers, in my experience (and to my taste). If want traditional package management, you can't go wrong with either.
- fsckboy 4y agowhat are you calling the new school?
- howinteresting 4y agoNix probably?
- pxc 4y agoYep, but I'd also count some package managers which have learned from Nix but chosen a slightly different path by relaxing the requirement of 'purity', or leaning harder on containerization features. Besides the ones I mentioned in my reply which is a sibling to yours, I think the package managers for Haiku and RedoxOS fall into this category (but I can't be sure! I've never used them, so my memory of how where work is likely to have gaps).
- pxc 4y agoThere isn't a single one, but off the top of my head, the following package managers have been used to meet the same need (building Linux distros) but use distinct and relatively new paradigms or techniques: - Guix, Nix - Distri - Luet (I'm personally partial to the 'functional' school, which means Nix and Guix. :) One might also count package managers that are designed for building large, multi-language distributions of software but have never been used to build a whole distro. In that case, you could also include - Spack - Denxi and finally you might also include tools that build on top of the traditional stuff, like `rpm-ostree`. This is what you're dealing with on Fedora Silverblue, SteamOS, openSUSE MicroOS, etc. Also distinct from these but not particularly new are source-based package management systems, like - source-based Linux distro package managers incl. - emerge - paludis - sorcery - various ports systems, incl. - pkgsrc - Ravenports - FreeBSD Ports - Dragonfly BSD's DPorts - MacPorts - Homebrew but those aren't really in the mainstream of system-wide package management, at least from my Linux-centric perspective, so I don't usually mean them when I refer to 'traditional' or 'conventional' package managers without any other qualifiers. Anyway yeah, plain old openSUSE and Fedora are great choices if you don't want a declarative system or immutable Linux, and that is in part because zypper and dnf are best-in-class for their paradigm.
- fsckboy 4y agowow, thank you! but are there linux distros that use any of these "from scratch" or as their native system for updating the kernel and reconfiguring grub, etc? or, to ask a different way, could these systems do that?
- Nullabillity 4y agoNixOS and GuixSD are distros built entirely around Nix and Guix, respectively.
- pxc 4y agoIn a word: yes! That I know of, Guix, Nix, and Luet are the only ones with whole, bootable Linux distros built on top of them so that the 'package manager' also does configuration management in some form. (IIRC, Luet is more traditional here, it manages config files only state fully and partially, using hooks and triggers.) The operating systems built on them are GuixSD, NixOS, and MoccacinoOS, respectively. I'm not sure what the status of MoccacinoOS is, but GuixSD and NixOS are very usable and very worth checking out. Distri is a system-wide package manager, but its distro is a PoC. It has a small package collection and no users, last I checked. But it has some cool innovations and it's very fast, so if you want to play with building a distro on a next-gen package manager, it seems great! I think Denxi could be used to build an OS in a similar way as Nix, but I'm not aware of any such effort currently. The same is true of Spack. Haiku and RedoxOS have some fancy Nix-like package management features as well, in terms of rollbacks and multiple versions of transitive dependencies playing nice together on the same system, and maybe in some other ways, too.
- DivineBicycle 4y agoHave you ever tried pacman? I’ve used pacman, zypper, dnf, apt, and apk (a few times), and found that (for me) pacman is the best, with its flags, while not making sense to a beginner, are very versatile, e.g. -Syu (sync and update all packages), -Rsn (remove a package and all its dependencies unneeded by other packages and its config files), etc. apk might be a tad faster, but I’ve found pacman to be much faster than dnf, although I can’t remember exactly how fast zypper is since it’s been a few months since I used OpenSUSE. PKGBUILDs are also a great part of the pacman system, and while I’ve not written any yet myself, I can mostly understand what they are doing, and I’m fairly sure I would be able to write one if needed, whereas when I tried to write an RPMspec (? might have gotten that name wrong) I gave up after an hour of trying.
- pxc 4y ago> Have you ever tried pacman? I have! I'm personally not a fan. I've generally experienced pacman as incomplete, brittle, and clunky. For me, giving up the speed of pacman for the robustness, flexibility, nicer CLI, and feature completeness of dnf or zypper is an easy tradeoff to make. > I’ve found pacman to be much faster than dnf, although I can’t remember exactly how fast zypper is since it’s been a few months since I used OpenSUSE Compared to pacman, zypper is slow like dnf— probably slightly slower. > PKGBUILDs are also a great part of the pacman system, and while I’ve not written any yet myself, I can mostly understand what they are doing, and I’m fairly sure I would be able to write one if needed, whereas when I tried to write an RPMspec (? might have gotten that name wrong) I gave up after an hour of trying. It's been a long time since I ran openSUSE on the daily, but when I did I managed a repo of RPM packages and I'm pretty sure I created at least some of their spec files from scratch, although most were downstream forks or packages I imported from elsewhere. I don't know what made it click for me, but I found it a little easier than DEB packaging (maybe in part because I learned it later), and definitely manageable. But I hear you: PKGBUILDs are widely praised for their simplicity, and it clearly helps a lot of people make good use of the packaging system. That's a real strength.
- DivineBicycle 4y ago> incomplete, brittle, and clunky. I don’t see where you might experience incompleteness in pacman, although I might see how you could experience it to be clunky. Do you mind humouring me and explaining this further? > flexibility I’m also not sure where dnf is more flexible, although I probably never explored it fully. What do you find about pacman to be inflexible? > nicer CLI This I most definitely understand. Even after over a year of using pacman I don’t try to understand why flags are named what they are (looking at you —-Sync), but having memorised them I do quite enjoy pacman. > I’m fairly sure I created at least some of their spec files from scratch It could just be my low intellect manifesting itself I suppose, so next time I have a Linux install using rpm I’ll try again. Thanks for replying to my questions, it’s always interesting to hear from Linux veterans!