DNF vs ZYpp: Fight!
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Gompa, Neal
In one corner, we have Zypper: the successor to the motley of package management options from Ximian and SuSE. Created after the merger of the Ximian and YaST package manager teams, it was a pioneer in using the SAT solver for package management and proved that it worked well at scale in a large and popular Linux distribution platform (SUSE Linux). It spawned the development of libsatsolver, which became libsolv. Considered by many to be the most advanced and fastest package manager, it is created a class of package managers all on its own. It is used in openSUSE, but is also available in Fedora and other RPM-based Linux distributions. In the other corner, we have DNF: the anointed successor to YUM (Yellowdog Updater, Modified). DNF (Dandified YUM) was forked from YUM to rework the internals to leverage libsolv and offer a saner, more maintainable API. Forged from the blood, sweat, and tears of many package manager developers from Red Hat and others, DNF is built with the lessons in mind from the last decade of software and systems management experiences. A new up and comer, it is used in Fedora, Mageia, OpenMandriva, Yocto, and others. It is also available in openSUSE. How do these two package managers compare? Are they more similar than different? Has DNF made YUM no longer a trash heap? Does ZYpp still rule the roost? This talk explores both package managers and compares them from a technical, usability, and ecosystem perspective. Who knows? Perhaps there are lessons to still be learned for evolving both package managers.
 Hello, everyone. So, my name is Neil Gampa. I'm a contributor in Fedora Project as well as in OpenSuzan and whatnot. And here I'm to talk about like DNF versus Zipper, you know, fight, because, you know, why not? So, a little bit about who I am. I'm sort of a self-styled open source advocate. I'm a contributor in package maintainer in Fedora, Magia and OpenSuzan. And I've contributed to RPM, DNF, Zipper, Kiwi, the OpenBuild service and a number of the system management-based stuff. For my day job, I'm a DevOps engineer at Datto, a disaster recovery backup business continuity company. And part of my role involves managing the release engineering of our software, including running an OBS instance internally and doing terrible package backport things, because, you know, that's what always happens when you're in a corporate environment. So, let's kind of start with introducing the two package managers. So, to begin with, like, the one that most of y'all probably aren't too familiar with, if the slide would move, there we go. DNF. So, it's a successor to the Yellow Dog Updater modified or YUM, as a lot of people may vaguely know of from the Red Hat ecosystem. It was forked from YUM about five, six years ago to rework the internals to use the Libsolv library and to offer a saner maintainable API. It offers a defined plugin architecture for extending the package manager functionality. It is the package manager in Fedora, Open Mandrieva, Yachto, and now Red Hat Enterprise Linux as of REL 8. It is available also as a supported package manager in Magia. It is included in OpenSusa as of LEAP-150, and it actually was included in REL 7 as of REL 7.6 as an option for you to use instead of crappy old YUM. And then, of course, the classical zipper thing. You guys all kind of know this. It's the package manager that made a whole new class of package managers in itself. With SAT Solving at a large scale, it replaced the motley of crazy-ass package management options that we all inherited from Zimian and Sousa back when the two companies kind of came together when Novel bought them both. Spawn the development of the Libset Solver, which became Libsolv. It is used primarily today in, of course, the Sousa distributions as well as Tizen. And it is also in Fedora since Fedora 26, courtesy of yours truly. So it is kind of functional all the way through Fedora 28. After that, not so much. So some of the similarities here, I mean, because there are, of course, similarities between the two. So they both use Libsolv for dependency resolution. The low-level aspects of both package managers are in C and C++. Plugins are supported in the base library interfaces, and they both work with package kit. So like anything that's leveraging package kit on these distributions that use the DNF or zipper will be able to leverage those backends correctly. They exclusively handle RPM metadata repositories. This technically wasn't true in the past because zipper used to handle YAS repos, but it doesn't anymore. It silently says, well, YAS, repos don't exist. We're going to do RPM repos instead. And both of them actually do support fairly well being able to build custom front-end interfaces. And, of course, arbitrary subcommands through extending through either modules, Python modules, or C++ programs or whatnot. The user experience between the two is actually fairly similar as well. The CLI interface structure is the same. It's the tool with the action, with the arguments for the action. Subcommands in both DNF and zipper have standard abbreviated forms. This is something that maybe some people aren't familiar with, that in the DNF package manager, they've kind of adopted the same technique that the zipper people have, where common subcommands have a short form that's easier to type and remember so that you don't necessarily require bash completion to be able to get to them. And, of course, the CLI supports colors when the terminal supports it and will help you distinguish stuff when the colors are activated. There's graphical front-ends to offer more intuitive user-friendly ways to do software management as well, of course. But there's a fair bit of differences, too. The underlying differences between DNF and ZipStack are actually quite significant. The biggest one is that the underlying architecture for the DNF stack is very, very modular. It is split up across five or six libraries if we exclude librpm itself and libsolve, whereas the ZipStack is one library when you exclude all of that, when you exclude those. One thing that's a little bit scary and surprising is that Zipper actually installs packages by subprocessing out to the rpm command. From what I understand, from eons gone by, they couldn't trust librpm to do the right thing, so they subprocessed it and did scary things to make sure everything looked like it worked. DNF, however, has no such compunction and uses librpm to install things directly. So the transaction is handled directly by rpm through the library interface and doesn't look quite as terrifying from the 10,000 feet view. The way that you install collections of packages is slightly different between DNF and Zipper because of the composition groups and now new module metadata stuff. So Fedora has this new modularity thing, which has a new extra metadata format with more stuff and it's kind of complicated, but it adds more things to how DNF can handle collections of packages, whereas of course Zipper has the patterns, which you all are familiar, are basically very fancy meta packages with extra properties attached to them so that Zipper knows how to find them. One of the things that was actually kind of surprising when I first started comparing the two stacks years ago when I was first looking at this was that language bindings in Zipper are actually in a pretty poor state. The zip bindings thing is not in good shape and is essentially unsupported and don't work, whereas in the DNF stack as a consequence of how the front ends are implemented and some of the legacy language bindings in the libraries are actually a first class citizen and while it only currently supports Python, more languages are expected to follow in the near future. And DNF also has an implementation that exports the API as a debuff interface for applications to interrogate and manipulate through that manner if they wish. That's something that as far as I'm aware only a yum DNF and apt actually have some form of this. Not very many package managers have a direct way to be interrogated via debuffs. The user experience is actually somewhat different as well, but not too much so. DNF has the feature of aliases, which it inherits from yum, so you can have sub-commands that you can define that are built on standard commands with options and things like that so you can make short forms of custom short forms of whatever you want. Another thing that DNF does that is different from Zipper is that you can actually install any package based on any file path that is known by the repository because DNF actually parses the file lists completely and handles that in its solver pool, whereas Zipper does not normally do that. And there's multiple native graphical front ends. Zipper has, to its credit, it has strangely enough a machine readable output form XML for its output so that it can be manipulated from other tools through shell, script, and awk, and pearl, and stuff like that. One really neat thing that it does is that it can split transactions up into smaller chunks if it detects a low disk situation or if there's a special solver situation that requires splitting the transaction up. That is really handy when you're working with laptops and with small SSDs or netbooks and things like that, and that's a really nice fancy feature to have. Unfortunately, Yast is the only graphical front end that exists for it. Yast is cool and all, but the fact that there isn't an independent front end that kind of just works on its own makes it a little difficult to demonstrate how well to use the libzip API for building such things. So, yeah. As far as the ecosystem goes, we can kind of start with the development activity of the actual package manager software itself as soon as that shows up. There we go. So, for DNF, the first, for DNF and Zipper, the two ones at the top are actually the command line front end. So, you can see that the DNF one starts in 2002. That's because it was forked from YAM. So, if you ignore everything before 2012, that's all, 2012 and earlier is all YAM code. Forward on that is DNF. And in Zipper, you can also see that by comparison, there isn't a whole lot going on in the CLI land. That's because, unlike in DNF, Zippers stack, the CLI doesn't actually have a whole lot of logic in it. Most of it is in the library. And so, you can see comparatively, libzip has a lot more code going on in there. Whereas, on the DNF side, it's a little bit mixed. There's a lot of business logic in both the CLI front end as well as in the libraries. And that's something, hopefully, that will be fixed over time. In terms of, like, how the ecosystem tends to use this, the plugins and extensions model is something that is very well supported in DNF. And it's something that I think actually has been a really good boost to how that has been used by a lot of people. Because the API is now stabilized and well-defined, there's been a lot of plugins and extensions for supporting interesting workflows and tools and things like that. There's, like, over 25 officially supported plugins off the top of my head. I know of at least a dozen more that people have written that they're using. And then there's also things like Salt and Ansible, which poke the DNF API directly because they can and they know that that stuff is going to work. And that allows them to do more creative things when they need to. For Zipper, I'm actually not too certain if there were that many plugins that were written for it. I could only really find a few major ones, like the one for Spacewalk, Susan Manager, and the customer center package search plugin. Those are the only ones I could really find. I couldn't really find too many others. The methods to support plugins and extensions doesn't seem to be that well documented or pointed out anywhere. It was a little curious because, like, from what I could tell, it is supposed to be capable of it. It's just not used, which I'm a little weirded out about. But another bit, like as I mentioned earlier, there was also graphical front-ends for the DNF stack, multiples of them. And, of course, is because the CLI is scary. It's, ooh. But aside from the package kit front-ends, like NOM Software and Blasma Discover, there's a few native front-ends that exist for it. The first was actually Yumx DNF, which was the Yumx tender DNF flavor. That project is now defunct, and it's been superseded by DNF Degora, which is from the Magia project, and SimpleDNF, which is made by some independent developer who wanted to make a much simpler GTK-based front-end. Actually, I think it's brand new. I only found it, like, a couple of weeks ago. And so I'm going to show you just a little bit of that stuff with the DNF things. So let's see here. Oh, come on. Don't do this to me now. Fine. Let me kill this. And then let's go over here. Let's start this. Okay. Okay. There we go. So here I pre-loaded a transaction here to show. So let's make this a little bit more simple. Whoa. That is not what I wanted. So if you see what is... Oh, I see what is going on here. So if you see over here, this is... I'm about to execute a transaction to actually do the equivalent of zippered up on a tumbleweed system. I actually already pre-downloaded the whole transaction because, well, it took like seven hours in my hotel room to download everything. So I figured I didn't want to trust Wi-Fi to work or something like that. So I should also kill the test transaction part. Let's see. So I'm also using a short form here, desync. I could actually, if I wanted to be super clever, we'll just use dup. So dup. So that shows all the stuff that's going to happen. It's going to install 160 packages, upgrade 1.5K of them, remove and downgrade a few, do a thing. Already downloaded all of it. So it's going to run a transaction check and actually do the thing. And then, meanwhile... And then over here, I have DNF-Degora set up to install some things. I've checked a few packages and then build transaction. This is why you don't do demos. Let's see here. There we go. Now it shows all the stuff. And so this is... You know, it's basically the same kind of output you'd see from the CLI or if you're familiar with the ask, you'll see something like this when it's about to propose a transaction to you. It's just going to make me type in my password again. And now it's going to download... Wow, the Wi-Fi works here. So it's downloading packages and it's going to do stuff while that's happening. Then over here, you can see it's doing basically the same thing. It's upgrading the packages, running through the scriptlets and stuff. Actually, something that I learned while I was doing this, we run a lot of scriptlets during an upgrade in OpenSUSA. Like, a lot. Far more than I actually expected to. But it was an interesting exercise because it showed that, for one, OpenSUSA does do stuff the right way because even swapping from Zipper to DNF, things work fairly well. You can see all the output. It does all the right ordering and installation and stuff. It's nothing too special or crazy. Actually, this virtual machine has been upgraded like three times using DNF rather than Zipper. Nothing has exploded so far. So, we'll just go back to this. Beach ball of doom. All right, so since that kind of shows what was going on in there, the kind of conclusions I came from this was the DNF package manager and the Zipper package manager are actually fairly comparable at this point. In terms of user experience, performance, and usability, they're pretty up there. They're pretty good with each other and they're pretty good as package managers as a whole. I'm a little bit disappointed when I looked at how the sausage was made for Zipper, like how some of the stuff actually worked inside compared to, maybe it's again part of the fact that Zipper is so much older and they trusted the underlying stack a lot less. But it's a little bit weird, the kind of hacks that are in there that I feel like somebody should take a second look at and maybe think maybe they're no longer needed to work this way. Another thing that was sort of a thing was it feels like somebody needs to care about developing a little community around it. Zipper is a perfectly serviceable package manager and it's totally a good replacement for a lot of subpar package managers in the RPM ecosystem. But it seems like there's not much attempt to really drive adoption or usage of that. Supporting plugins and extensions is hard and zip is, well, fill in your own word but I would say zip is pretty awesome. For the DNF side, the architecture is kind of complicated. It's a little hard to follow how all the pieces fit together. On the flip, I think the community is pretty strong. That's maybe partly my fault but there's a large number of people that are actually using it and building tools around it and doing things like that. The language binding support beyond Python is still missing and I think it kind of comes away that DNF makes you really not suck. It has a good CLI interface. The performance is pretty good. The extensibility is awesome and generally I enjoy it. You shouldn't have to say like I, it's not that I don't want to say I love working with my packages all the time but it doesn't make it a chore to deal with all of them. In summary, I guess Zipper is probably still slightly up there higher than what DNF is but I think there's potential in both ways. There's still a bunch to learn from both of them. DNF does certain things a little bit better than I think Zipper does and vice versa as I've kind of mentioned earlier. Questions? Okay. Yeah. So the question was, is there, to simplify this, is the question was, is there an RPM based package manager that does source to binary reproducibility for verification before installation? The answer to this is no. One, that is extremely expensive. That requires setting up build routes or worse, installing all the build dependencies on the computer first before installing the, before building it and then installing the real package at the end and then probably figuring out a way to track all the build dependencies to remove afterwards because you don't need them. Two, it's not strictly necessary most of the time. Most people who are building RPMs are hopefully using a build system that's worth a damn like OBS or Koji which provides source to binary guarantees and reproducibility that lets you make sure you are not doing dumb things in your packages. And usually the repository metadata can be verified to ensure it's not tampered with either through checksums, meta-links, GPG checks or a combination of those. And with that you can usually trace from there to the binary package, check the checksum and the signatures of those and then install there. So you have enough paths of verification that it's usually not necessary to go down the extra mile of rebuild and then install to verify the reproducibility there. Usually that's the kind of stuff you'd want to do server side in a build farm like in an OBS or Koji setup. But there are bits and pieces of that functionality in both package managers. Zipper has a function called source install which allows you to download or point it to a source RPM and that will go and read it and install all the build dependencies and unpack it into an RPM build directory or whatnot so that you could just go ahead and build the package yourself if you'd like. DNF has the build depth sub-command which allows it to read a spec file or a source package and install the build dependencies and then you could do whatever you want there but it doesn't have an equivalent to the source install functionality. It might get it someday but right now it doesn't have it. But that's kind of the closest you get. Other package managers like URPMI, user RPM from Mantriva, they have the ability to download and unpack just like Zipper does. Apped RPM doesn't have any of this functionality. It really tries to ignore the fact that source packages exist. And Pull Deck and others are just kind of waffly on what to do with this kind of thing. So it's not really a thing that a lot of the RPM package managers concern themselves too much with. Yeah? You mean group installation as in like installing from using one command to a bunch of computers at once? Or do you mean installing a bunch of packages? The latter. Okay. So group installation in terms of installing a bunch of packages. In the DNF stack you have this through the composition groups or comps groups as a lot of people call it. And now with the module MD, so the module metadata and the comps groups, what they are essentially are metadata files that describe a set of packages that belong for a specific role or type or some logical grouping of some kind that a user may want to act upon. So they want to install it or remove it or upgrade them together or something like that. Zipper has this kind of similar behavior with patterns. It treats the meta packages slightly differently in pattern mode and tries to accomplish the same behavior. And the reason it used to be that patterns were special metadata like comps groups were, like comps groups are, sorry. But nowadays it is just meta packages with fancy labels and stuff inside. But essentially both package managers provide that kind of functionality. For zipper, it is zipper install dash t pattern, name of pattern. And for DNF, it is DNF install at sign name of group or name of module and it will go ahead and do the thing to install a collection of packages together. And it tracks those collections as they are installed, uninstalled, upgraded and whatnot. So you will know whether a package was installed as part of a group or if it was installed individually. Yeah? So good question. The question was, does DNF have any special behavior for handling when a user explicitly removes a sub dependency or a weak dependency, weak installed package? The answer to this question, unfortunately right now, is no. However, because DNF tracks the reason in which a package is installed and actually already has the information to make these kinds of decisions, the only reason right now it doesn't do things like automatically excluding a weak installed package that a user has explicitly removed is because no one has written the logic to do that. Like all the pieces are there, it is just the filter is not actually wired up yet. There was actually an effort a couple of years ago to redo how DNF stores its reason information. They now call it software database. It used to be a descendant of the YUM database. It is essentially a database that tracks all the transactions that have ever happened and also indicates like how the packages were installed and why. And that information also tracks when users decide to say I don't want this anymore and you uninstall it, it records that reason as well. Those reasons are currently not fully factored into the dependency solving but they could be. And if they were, then you could get more intelligent results out of that. Hello. Hello. You talked about DNF's module functions. Does it support any higher level functions for example dependencies between modules or comps or for example registering enterprise modules? Yeah. So unfortunately it does. So modules actually export the same level of interfaces and manipulation APIs that packages do. So you can install, remove, update, query them and modules can have module level dependencies. The way that the module stuff works is it's kind of a layer. You start with a repository layer at the bottom which has a super packages. Then you have module MDs that say these buckets of these soups of packages belong with these and then the buckets of packages inside are handled. So each layer it goes all the way down and DNF basically handles each of those as if they are like a package and you can do actions and things like that. Okay. So those are resolved using Libsolvn. Libsolvn knows nothing. Okay. Unfortunately, Libsolvn knows nothing right now. Part of this is because a lot of the behaviors related specifically to modules are not fully fleshed out to the point that we can start figuring out how they should work in Libsolv. Because it'd be unfair to everybody if we implemented it once and then it turned out like six months later, we have to change everything again. We kind of want to have a solid idea of how it's supposed to behave across the board before we want to do something like that and make Libsolv actually fully aware of them. For now, from Libsolv's point of view, it looks like DNF is saying I want to disable all these packages or I want to enable all these packages. These are in these filter groups. These are considered higher priority but it doesn't know why from the Libsolv point of view. Can you do anything like enterprise registrations of REL using DNF for a plugin? Yeah. I mean, the subscription management, sorry, the subscription management functionality has been integrated into the lower levels. So, for example, Red Hat subscription management actually now has a C library, LibRHSM, which is plugged into the LibDNF library as a plugin. And so if you are on a REL system, that plugin is built in and it will track your entitlements status and regenerate the Red Hat.repo file that is installed on there to include your repositories that you are entitled to. The subscription manager tool from Candlepin is the one that manipulates the settings for that and that's a Python program that lives a little bit outside of it. But it also wires into the DNF front end through its Python API to make sure that those things are all coherent. This should be done slightly more smoothly but that takes a little bit of work of figuring out how the interactions between the package manager and the entitlement management system need to be rationalized, especially in the part about handling a transition from talking to RHSM directly and talking to and switching over to a satellite system or a SUMA system or something like that. Any other questions? Okay. Well.
 Hello, everyone. So, my name is Neil Gampa. I'm a contributor in Fedora Project as well  as in OpenSuzan and whatnot. And here I'm to talk about like DNF versus Zipper, you  know, fight, because, you know, why not? So, a little bit about who I am. I'm sort of a  self-styled open source advocate. I'm a contributor in package maintainer in Fedora, Magia and  OpenSuzan. And I've contributed to RPM, DNF, Zipper, Kiwi, the OpenBuild service and a  number of the system management-based stuff. For my day job, I'm a DevOps engineer at Datto,  a disaster recovery backup business continuity company. And part of my role involves managing  the release engineering of our software, including running an OBS instance internally and doing  terrible package backport things, because, you know, that's what always happens when you're  in a corporate environment. So, let's kind of start with introducing the two package  managers. So, to begin with, like, the one that most of y'all probably aren't too familiar  with, if the slide would move, there we go. DNF. So, it's a successor to the Yellow Dog  Updater modified or YUM, as a lot of people may vaguely know of from the Red Hat ecosystem.  It was forked from YUM about five, six years ago to rework the internals to use the Libsolv  library and to offer a saner maintainable API. It offers a defined plugin architecture  for extending the package manager functionality. It is the package manager in Fedora, Open  Mandrieva, Yachto, and now Red Hat Enterprise Linux as of REL 8. It is available also as  a supported package manager in Magia. It is included in OpenSusa as of LEAP-150, and  it actually was included in REL 7 as of REL 7.6 as an option for you to use instead of  crappy old YUM. And then, of course, the classical zipper thing. You guys all kind of know this.  It's the package manager that made a whole new class of package managers in itself.  With SAT Solving at a large scale, it replaced the motley of crazy-ass package management  options that we all inherited from Zimian and Sousa back when the two companies kind  of came together when Novel bought them both. Spawn the development of the Libset Solver,  which became Libsolv. It is used primarily today in, of course, the Sousa distributions  as well as Tizen. And it is also in Fedora since Fedora 26, courtesy of yours truly.  So it is kind of functional all the way through Fedora 28. After that, not so much. So some  of the similarities here, I mean, because there are, of course, similarities between  the two. So they both use Libsolv for dependency resolution. The low-level aspects of both package  managers are in C and C++. Plugins are supported in the base library interfaces, and they both  work with package kit. So like anything that's leveraging package kit on these distributions  that use the DNF or zipper will be able to leverage those backends correctly. They exclusively  handle RPM metadata repositories. This technically wasn't true in the past because zipper used  to handle YAS repos, but it doesn't anymore. It silently says, well, YAS, repos don't  exist. We're going to do RPM repos instead. And both of them actually do support fairly  well being able to build custom front-end interfaces. And, of course, arbitrary subcommands  through extending through either modules, Python modules, or C++ programs or whatnot.  The user experience between the two is actually fairly similar as well. The CLI interface  structure is the same. It's the tool with the action, with the arguments for the action.  Subcommands in both DNF and zipper have standard abbreviated forms. This is something that  maybe some people aren't familiar with, that in the DNF package manager, they've kind of  adopted the same technique that the zipper people have, where common subcommands have  a short form that's easier to type and remember so that you don't necessarily require bash  completion to be able to get to them. And, of course, the CLI supports colors when the  terminal supports it and will help you distinguish stuff when the colors are activated. There's  graphical front-ends to offer more intuitive user-friendly ways to do software management  as well, of course. But there's a fair bit of differences, too. The underlying differences  between DNF and ZipStack are actually quite significant. The biggest one is that the underlying  architecture for the DNF stack is very, very modular. It is split up across five or six  libraries if we exclude librpm itself and libsolve, whereas the ZipStack is one library when you  exclude all of that, when you exclude those. One thing that's a little bit scary and surprising  is that Zipper actually installs packages by subprocessing out to the rpm command. From  what I understand, from eons gone by, they couldn't trust librpm to do the right thing,  so they subprocessed it and did scary things to make sure everything looked like it worked.  DNF, however, has no such compunction and uses librpm to install things directly. So  the transaction is handled directly by rpm through the library interface and doesn't  look quite as terrifying from the 10,000 feet view. The way that you install collections  of packages is slightly different between DNF and Zipper because of the composition  groups and now new module metadata stuff. So Fedora has this new modularity thing, which  has a new extra metadata format with more stuff and it's kind of complicated, but it  adds more things to how DNF can handle collections of packages, whereas of course Zipper has  the patterns, which you all are familiar, are basically very fancy meta packages with  extra properties attached to them so that Zipper knows how to find them. One of the  things that was actually kind of surprising when I first started comparing the two stacks  years ago when I was first looking at this was that language bindings in Zipper are  actually in a pretty poor state. The zip bindings thing is not in good shape and is essentially  unsupported and don't work, whereas in the DNF stack as a consequence of how the front  ends are implemented and some of the legacy language bindings in the libraries are actually  a first class citizen and while it only currently supports Python, more languages are expected  to follow in the near future. And DNF also has an implementation that exports the API  as a debuff interface for applications to interrogate and manipulate through that manner  if they wish. That's something that as far as I'm aware only a yum DNF and apt actually  have some form of this. Not very many package managers have a direct way to be interrogated  via debuffs. The user experience is actually somewhat different as well, but not too much  so. DNF has the feature of aliases, which it inherits from yum, so you can have sub-commands  that you can define that are built on standard commands with options and things like that  so you can make short forms of custom short forms of whatever you want. Another thing  that DNF does that is different from Zipper is that you can actually install any package  based on any file path that is known by the repository because DNF actually parses the  file lists completely and handles that in its solver pool, whereas Zipper does not normally  do that. And there's multiple native graphical front ends. Zipper has, to its credit, it  has strangely enough a machine readable output form XML for its output so that it can be  manipulated from other tools through shell, script, and awk, and pearl, and stuff like  that. One really neat thing that it does is that it can split transactions up into smaller  chunks if it detects a low disk situation or if there's a special solver situation that  requires splitting the transaction up. That is really handy when you're working with laptops  and with small SSDs or netbooks and things like that, and that's a really nice fancy  feature to have. Unfortunately, Yast is the only graphical front end that exists for it.  Yast is cool and all, but the fact that there isn't an independent front end that kind of  just works on its own makes it a little difficult to demonstrate how well to use the libzip API  for building such things. So, yeah. As far as the ecosystem goes, we can kind  of start with the development activity of the actual package manager software itself  as soon as that shows up. There we go. So, for DNF, the first, for DNF and Zipper, the  two ones at the top are actually the command line front end. So, you can see that the DNF  one starts in 2002. That's because it was forked from YAM. So, if you ignore everything  before 2012, that's all, 2012 and earlier is all YAM code. Forward on that is DNF.  And in Zipper, you can also see that by comparison, there isn't a whole lot going on in the CLI  land. That's because, unlike in DNF, Zippers stack, the CLI doesn't actually have a whole  lot of logic in it. Most of it is in the library. And so, you can see comparatively, libzip has  a lot more code going on in there. Whereas, on the DNF side, it's a little bit mixed.  There's a lot of business logic in both the CLI front end as well as in the libraries.  And that's something, hopefully, that will be fixed over time. In terms of, like, how  the ecosystem tends to use this, the plugins and extensions model is something that is very  well supported in DNF. And it's something that I think actually has been a really good  boost to how that has been used by a lot of people. Because the API is now stabilized  and well-defined, there's been a lot of plugins and extensions for supporting interesting workflows  and tools and things like that. There's, like, over 25 officially supported plugins off  the top of my head. I know of at least a dozen more that people have written that they're  using. And then there's also things like Salt and Ansible, which poke the DNF API directly  because they can and they know that that stuff is going to work. And that allows them to  do more creative things when they need to. For Zipper, I'm actually not too certain if  there were that many plugins that were written for it. I could only really find a few major  ones, like the one for Spacewalk, Susan Manager, and the customer center package search plugin.  Those are the only ones I could really find. I couldn't really find too many others. The  methods to support plugins and extensions doesn't seem to be that well documented or  pointed out anywhere. It was a little curious because, like, from what I could tell, it  is supposed to be capable of it. It's just not used, which I'm a little weirded out about.  But another bit, like as I mentioned earlier, there was also graphical front-ends for the  DNF stack, multiples of them. And, of course, is because the CLI is scary. It's, ooh. But  aside from the package kit front-ends, like NOM Software and Blasma Discover, there's  a few native front-ends that exist for it. The first was actually Yumx DNF, which was  the Yumx tender DNF flavor. That project is now defunct, and it's been superseded by  DNF Degora, which is from the Magia project, and SimpleDNF, which is made by some independent  developer who wanted to make a much simpler GTK-based front-end. Actually, I think it's  brand new. I only found it, like, a couple of weeks ago. And so I'm going to show you  just a little bit of that stuff with the DNF things. So let's see here. Oh, come on. Don't  do this to me now. Fine. Let me kill this. And then let's go over here. Let's start this.  Okay.  Okay.  There we go. So here I pre-loaded a transaction here to show. So let's make this a little  bit more simple. Whoa. That is not what I wanted. So if you see what is... Oh, I see  what is going on here. So if you see over here, this is... I'm about to execute a transaction  to actually do the equivalent of zippered up on a tumbleweed system. I actually already  pre-downloaded the whole transaction because, well, it took like seven hours in my hotel  room to download everything. So I figured I didn't want to trust Wi-Fi to work or something  like that. So I should also kill the test transaction part. Let's see. So I'm also using  a short form here, desync. I could actually, if I wanted to be super clever, we'll just  use dup. So dup. So that shows all the stuff that's going to happen. It's going to install  160 packages, upgrade 1.5K of them, remove and downgrade a few, do a thing. Already  downloaded all of it. So it's going to run a transaction check and actually do the thing.  And then, meanwhile... And then over here, I have DNF-Degora set up to install some things.  I've checked a few packages and then build transaction. This is why you don't do demos.  Let's see here. There we go. Now it shows all the stuff. And so this is... You know,  it's basically the same kind of output you'd see from the CLI or if you're familiar with  the ask, you'll see something like this when it's about to propose a transaction to you.  It's just going to make me type in my password again. And now it's going to download... Wow,  the Wi-Fi works here. So it's downloading packages and it's going to do stuff while  that's happening. Then over here, you can see it's doing basically the same thing. It's  upgrading the packages, running through the scriptlets and stuff. Actually, something  that I learned while I was doing this, we run a lot of scriptlets during an upgrade  in OpenSUSA. Like, a lot. Far more than I actually expected to. But it was an interesting exercise  because it showed that, for one, OpenSUSA does do stuff the right way because even swapping  from Zipper to DNF, things work fairly well. You can see all the output. It does all the  right ordering and installation and stuff. It's nothing too special or crazy. Actually,  this virtual machine has been upgraded like three times using DNF rather than Zipper.  Nothing has exploded so far. So, we'll just go back to this. Beach ball of doom. All right,  so since that kind of shows what was going on in there, the kind of conclusions I came  from this was the DNF package manager and the Zipper package manager are actually fairly  comparable at this point. In terms of user experience, performance, and usability, they're  pretty up there. They're pretty good with each other and they're pretty good as package  managers as a whole. I'm a little bit disappointed when I looked at how the sausage was made  for Zipper, like how some of the stuff actually worked inside compared to, maybe it's again  part of the fact that Zipper is so much older and they trusted the underlying stack a lot  less. But it's a little bit weird, the kind of hacks that are in there that I feel like  somebody should take a second look at and maybe think maybe they're no longer needed  to work this way. Another thing that was sort of a thing was it feels like somebody needs  to care about developing a little community around it. Zipper is a perfectly serviceable  package manager and it's totally a good replacement for a lot of subpar package managers in the  RPM ecosystem. But it seems like there's not much attempt to really drive adoption or  usage of that. Supporting plugins and extensions is hard and zip is, well, fill in your own  word but I would say zip is pretty awesome. For the DNF side, the architecture is kind  of complicated. It's a little hard to follow how all the pieces fit together. On the flip,  I think the community is pretty strong. That's maybe partly my fault but there's a large  number of people that are actually using it and building tools around it and doing things  like that. The language binding support beyond Python is still missing and I think it kind  of comes away that DNF makes you really not suck. It has a good CLI interface. The performance  is pretty good. The extensibility is awesome and generally I enjoy it. You shouldn't have  to say like I, it's not that I don't want to say I love working with my packages all  the time but it doesn't make it a chore to deal with all of them. In summary, I guess  Zipper is probably still slightly up there higher than what DNF is but I think there's  potential in both ways. There's still a bunch to learn from both of them. DNF does certain  things a little bit better than I think Zipper does and vice versa as I've kind of mentioned  earlier.  Questions? Okay. Yeah.  So the question was, is there, to simplify this, is the question was, is there an RPM  based package manager that does source to binary reproducibility for verification before  installation? The answer to this is no. One, that is extremely expensive. That requires  setting up build routes or worse, installing all the build dependencies on the computer  first before installing the, before building it and then installing the real package at  the end and then probably figuring out a way to track all the build dependencies to remove  afterwards because you don't need them. Two, it's not strictly necessary most of the time.  Most people who are building RPMs are hopefully using a build system that's worth a damn  like OBS or Koji which provides source to binary guarantees and reproducibility that  lets you make sure you are not doing dumb things in your packages. And usually the repository  metadata can be verified to ensure it's not tampered with either through checksums, meta-links,  GPG checks or a combination of those. And with that you can usually trace from there  to the binary package, check the checksum and the signatures of those and then install  there. So you have enough paths of verification that it's usually not necessary to go down  the extra mile of rebuild and then install to verify the reproducibility there. Usually  that's the kind of stuff you'd want to do server side in a build farm like in an OBS  or Koji setup. But there are bits and pieces of that functionality in both package managers.  Zipper has a function called source install which allows you to download or point it to  a source RPM and that will go and read it and install all the build dependencies and unpack  it into an RPM build directory or whatnot so that you could just go ahead and build  the package yourself if you'd like. DNF has the build depth sub-command which allows  it to read a spec file or a source package and install the build dependencies and then  you could do whatever you want there but it doesn't have an equivalent to the source install  functionality. It might get it someday but right now it doesn't have it. But that's kind  of the closest you get. Other package managers like URPMI, user RPM from Mantriva, they have  the ability to download and unpack just like Zipper does. Apped RPM doesn't have any of  this functionality. It really tries to ignore the fact that source packages exist. And Pull  Deck and others are just kind of waffly on what to do with this kind of thing. So it's  not really a thing that a lot of the RPM package managers concern themselves too much with.  Yeah? You mean group installation as in like installing from using one command to a bunch  of computers at once? Or do you mean installing a bunch of packages? The latter. Okay. So group  installation in terms of installing a bunch of packages. In the DNF stack you have this  through the composition groups or comps groups as a lot of people call it. And now with the  module MD, so the module metadata and the comps groups, what they are essentially are  metadata files that describe a set of packages that belong for a specific role or type or  some logical grouping of some kind that a user may want to act upon. So they want to  install it or remove it or upgrade them together or something like that. Zipper has this kind  of similar behavior with patterns. It treats the meta packages slightly differently in  pattern mode and tries to accomplish the same behavior. And the reason it used to be that  patterns were special metadata like comps groups were, like comps groups are, sorry.  But nowadays it is just meta packages with fancy labels and stuff inside. But essentially  both package managers provide that kind of functionality. For zipper, it is zipper install  dash t pattern, name of pattern. And for DNF, it is DNF install at sign name of group or  name of module and it will go ahead and do the thing to install a collection of packages  together. And it tracks those collections as they are installed, uninstalled, upgraded  and whatnot. So you will know whether a package was installed as part of a group or if it  was installed individually. Yeah? So good question. The question was, does DNF have  any special behavior for handling when a user explicitly removes a sub dependency or a weak  dependency, weak installed package? The answer to this question, unfortunately right now,  is no. However, because DNF tracks the reason in which a package is installed and actually  already has the information to make these kinds of decisions, the only reason right  now it doesn't do things like automatically excluding a weak installed package that a user  has explicitly removed is because no one has written the logic to do that. Like all the  pieces are there, it is just the filter is not actually wired up yet. There was actually  an effort a couple of years ago to redo how DNF stores its reason information. They now  call it software database. It used to be a descendant of the YUM database. It is essentially  a database that tracks all the transactions that have ever happened and also indicates  like how the packages were installed and why. And that information also tracks when users  decide to say I don't want this anymore and you uninstall it, it records that reason as  well. Those reasons are currently not fully factored into the dependency solving but they  could be. And if they were, then you could get more intelligent results out of that.  Hello. Hello. You talked about DNF's module functions. Does it support any higher level  functions for example dependencies between modules or comps or for example registering  enterprise modules? Yeah. So unfortunately it does. So modules actually export the same  level of interfaces and manipulation APIs that packages do. So you can install, remove,  update, query them and modules can have module level dependencies. The way that the module  stuff works is it's kind of a layer. You start with a repository layer at the bottom which  has a super packages. Then you have module MDs that say these buckets of these soups  of packages belong with these and then the buckets of packages inside are handled. So  each layer it goes all the way down and DNF basically handles each of those as if they  are like a package and you can do actions and things like that. Okay. So those are resolved  using Libsolvn. Libsolvn knows nothing. Okay. Unfortunately, Libsolvn knows nothing right  now. Part of this is because a lot of the behaviors related specifically to modules  are not fully fleshed out to the point that we can start figuring out how they should  work in Libsolv. Because it'd be unfair to everybody if we implemented it once and then  it turned out like six months later, we have to change everything again. We kind of want  to have a solid idea of how it's supposed to behave across the board before we want  to do something like that and make Libsolv actually fully aware of them. For now, from  Libsolv's point of view, it looks like DNF is saying I want to disable all these packages  or I want to enable all these packages. These are in these filter groups. These are considered  higher priority but it doesn't know why from the Libsolv point of view.  Can you do anything like enterprise registrations of REL using DNF for a plugin?  Yeah. I mean, the subscription management, sorry, the subscription management functionality  has been integrated into the lower levels. So, for example, Red Hat subscription management  actually now has a C library, LibRHSM, which is plugged into the LibDNF library as a plugin.  And so if you are on a REL system, that plugin is built in and it will track your entitlements  status and regenerate the Red Hat.repo file that is installed on there to include your  repositories that you are entitled to. The subscription manager tool from Candlepin is  the one that manipulates the settings for that and that's a Python program that lives  a little bit outside of it. But it also wires into the DNF front end through its Python API  to make sure that those things are all coherent. This should be done slightly more smoothly  but that takes a little bit of work of figuring out how the interactions between the package  manager and the entitlement management system need to be rationalized, especially in the  part about handling a transition from talking to RHSM directly and talking to and switching  over to a satellite system or a SUMA system or something like that. Any other questions?  Okay. Well.
openSUSE_Conference_2019_-_DNF_vs_ZYpp__Fight__bTFl9n7JJXw_0_575.png openSUSE_Conference_2019_-_DNF_vs_ZYpp__Fight__bTFl9n7JJXw_576_1703.png openSUSE_Conference_2019_-_DNF_vs_ZYpp__Fight__bTFl9n7JJXw_1704_1979.png openSUSE_Conference_2019_-_DNF_vs_ZYpp__Fight__bTFl9n7JJXw_1980_4667.png openSUSE_Conference_2019_-_DNF_vs_ZYpp__Fight__bTFl9n7JJXw_4668_6011.png openSUSE_Conference_2019_-_DNF_vs_ZYpp__Fight__bTFl9n7JJXw_6012_12011.png openSUSE_Conference_2019_-_DNF_vs_ZYpp__Fight__bTFl9n7JJXw_12012_19931.png openSUSE_Conference_2019_-_DNF_vs_ZYpp__Fight__bTFl9n7JJXw_19932_20063.png openSUSE_Conference_2019_-_DNF_vs_ZYpp__Fight__bTFl9n7JJXw_20064_20267.png openSUSE_Conference_2019_-_DNF_vs_ZYpp__Fight__bTFl9n7JJXw_20268_20375.png openSUSE_Conference_2019_-_DNF_vs_ZYpp__Fight__bTFl9n7JJXw_20376_20819.png openSUSE_Conference_2019_-_DNF_vs_ZYpp__Fight__bTFl9n7JJXw_20820_21659.png openSUSE_Conference_2019_-_DNF_vs_ZYpp__Fight__bTFl9n7JJXw_21660_21779.png openSUSE_Conference_2019_-_DNF_vs_ZYpp__Fight__bTFl9n7JJXw_21780_22463.png openSUSE_Conference_2019_-_DNF_vs_ZYpp__Fight__bTFl9n7JJXw_22464_22655.png openSUSE_Conference_2019_-_DNF_vs_ZYpp__Fight__bTFl9n7JJXw_22656_22703.png openSUSE_Conference_2019_-_DNF_vs_ZYpp__Fight__bTFl9n7JJXw_22704_22775.png openSUSE_Conference_2019_-_DNF_vs_ZYpp__Fight__bTFl9n7JJXw_22776_25079.png openSUSE_Conference_2019_-_DNF_vs_ZYpp__Fight__bTFl9n7JJXw_25080_25511.png openSUSE_Conference_2019_-_DNF_vs_ZYpp__Fight__bTFl9n7JJXw_25512_26495.png openSUSE_Conference_2019_-_DNF_vs_ZYpp__Fight__bTFl9n7JJXw_26496_26687.png openSUSE_Conference_2019_-_DNF_vs_ZYpp__Fight__bTFl9n7JJXw_26688_26867.png openSUSE_Conference_2019_-_DNF_vs_ZYpp__Fight__bTFl9n7JJXw_26868_27215.png openSUSE_Conference_2019_-_DNF_vs_ZYpp__Fight__bTFl9n7JJXw_27216_27383.png openSUSE_Conference_2019_-_DNF_vs_ZYpp__Fight__bTFl9n7JJXw_27384_27491.png openSUSE_Conference_2019_-_DNF_vs_ZYpp__Fight__bTFl9n7JJXw_27492_27563.png openSUSE_Conference_2019_-_DNF_vs_ZYpp__Fight__bTFl9n7JJXw_27564_27755.png openSUSE_Conference_2019_-_DNF_vs_ZYpp__Fight__bTFl9n7JJXw_27756_27803.png openSUSE_Conference_2019_-_DNF_vs_ZYpp__Fight__bTFl9n7JJXw_27804_27887.png openSUSE_Conference_2019_-_DNF_vs_ZYpp__Fight__bTFl9n7JJXw_27888_28163.png openSUSE_Conference_2019_-_DNF_vs_ZYpp__Fight__bTFl9n7JJXw_28164_28535.png openSUSE_Conference_2019_-_DNF_vs_ZYpp__Fight__bTFl9n7JJXw_28536_48431.png openSUSE_Conference_2019_-_DNF_vs_ZYpp__Fight__bTFl9n7JJXw_48432_48530.png