 Welcome everybody, we are here to talk about DNF obviously. My name is Daniel Mach, I've been with Red Hat for, well, a decade. I've spent 10 years in release engineering and I've been leading the software management team for about two years. I'm mainly focused on DNF and I will have this presentation together with Jaroslav Raczek who is the longest serving DNF team member so far for three years. He's been focused on modularity and also some optimizations and performance tuning. So what's on the agenda? First of all, we will remind what DNF is. Then we will provide several details about the DNF stack and some statistics. Then we will quickly go through the achievements we have made over the last year. We will touch roadmap and future plans and then there will be space for questions and answers. So what is DNF? It's a package manager you may know from Fedora and it replaces YAM 3. It's also available as YAM 4 in Red Hat Enterprise Linux 8 beta. That's mainly for continuity and compatibility because the existing customers are used to use YAM so we provided that but it runs on the DNF backend and it's essentially the same software and it's also available in other distributions such as Magia, OpenSUSE or YoctoProject. This is a brief DNF stack overview. So on the left side, these are packages we maintain. You can see all the sources on GitHub and they are mainly also available in Fedora. Those which are in the vault, these are the main packages you may be using frequently, especially the DNF and the plugins. There are also some related projects such as RPM, Libsol, PackageKit, etc. All these belong to our ecosystem but we don't maintain them directly. Yarda, could you provide some details on the numbers? Formation about three of our projects. The first one is DNF. We can't hear you. We have some issues. You need to speak up or differently. DNF is a Python-based project. It is forked from YAM in 2012 and from that time we already have about 4,000 commits. DNF plugins is again the Python project. The last one I want to highlight is LibDNF. LibDNF is C++ library that is used as backend not only for DNF but also for the micro-DNF and PackageKit. What is most important? Okay, maybe let me continue until the technical issues get resolved. Check. Contributors and for the other two projects it's about 60. As you can see even in the last year we have so many active people. About our achievement, I have to talk about modularity. Maybe let me cover this slide before your microphone gets fixed. Modularity. We have shipped modularity tech preview in federal 28 that was mainly Python-based. The code was merely a proof of concept and we have rewritten it completely for federal 29 which is based on the LibDNF C++ implementation which is also available in PackageKit and other software. We have also made some improvements in the stack mainly the memory issues, memory leaks, double freeze and a lot of issues leading to sec faults. Give it a try. Is it on? Okay, so let's switch the sides. Okay, probably that was the issue. Okay, let's for the next slide please. All right. Okay, I pick up for the performance presentation three versions. The oldest one is from the federal 26, the middle one is from the federal 27 and the last one is just recently released into federal 29 and rail 8 beta. As you can see during the time already the first command provides a slightly improved in the performance but as you can see for the DNF update command we have a huge difference between the version from federal 27 and the latest one and similar approach you can see with the commands that use the security options like the security backfix. The last example here it represents how DNF handles a lot of arguments. In this example it was 3,000 arguments and already for the DNF 251 we can say that already this DNF that sounds like pretty slow it's much faster that yum is. Okay, maybe let me explain the latest results. As you can see it's a little bit over two seconds and those two seconds is the time required for loading all the repositories which is something we cannot probably get rid of but basically we can't trim from these times almost nothing because we are down to the overhead. All right, next slide. Okay, that's mine. Okay, so the first point is the new history database. I'm actually the author of the change and I can proudly say that we have managed to break quite a lot of stuff in the federal 29 pre-releases but luckily federal 29 final release is almost without any issues and everything seems to be working fine and why we were doing that. The original software database or the history database contained a lot of different tables in the SQLI database and we decided to redesign it to make it better and make sure that it contains the exact information that is needed across the DNF stack and that we know what the information is there and how to use it. Before that it was quite a black box and we really didn't know what's that all about. We also made a design decision on the DNF so we ended up coding that library in C++ and using SWIC to generate bindings. The main reason for that was to gain native objects, type containers and have bindings that are easy to generate. So basically we write C++ classes and we easily export them into Python. We have also introduced Cplugin API which is something quite new. It's quite, I would say, dangerous to use at the moment because we will get to that in the next slides. We are planning bigger changes in the C API and if anyone uses this LibDNF C API with all the library in C, we will change that. So this is the existing DNF stack infrastructure or architecture. As you can see it relies on LibDNF and LibDNF has quite a long history. It's made of original DNF backend, that's the Hockey library and then there's the C API, the Libhive, which originally comes from PackageKit and we ended up with these two libraries in a single source tree and the merge hasn't been finished yet. So we are currently working on making all these functions and all the code better and that leads also to a situation when micro DNF and PackageKit, they use the Libhive part and DNF is based on something else and cannot use the C plugins, for instance, at the moment. And Jarda will tell you what's the bright future. Yeah, this is the picture how we suggest the LibDNF should appear in near, near far future. It means we want to create a C++ API and on top of that we want to generate or as a wrapper C API or Python API or Python binding and of course the plugin API. The advantages is directly represented here that as you can see, as you can see plugins, API plugins can handle it also not only LibDNF, micro DNF PackageKit but also can be used or will be used with the DNF. It means it will some troubles from the components that use plugin. It could disappear. What is the most important thing about this is that if something breaks, it breaks in one place and we don't have to fix in three places as today. Yeah. All right. And when we start to think the plans for the next releases, for the Federal Security, we plan to deliver Zechang support. Zechang is a new compression format designed to allow Deltas for metadata. And as I can say, I think this is pretty promising technology how to decrease the downloads for the metadata. Additionally, according to the Fedora plan plans, we will drop Python 2 support. For the Fedora 31, we would like to deliver new improved modularity. According to the feedback, probably some of us will provide from the Fedora 29, 30 or even REL. Additionally, we would like to prepare for a redesign of the VAR cache. And this should result in the shared cache with micro DNF and package kit. Additionally, we have a huge plan with the CA stack. Can you provide the information? Sure. So, we have decided to rewrite our CA tests because we want to improve the performance, separate the tests from the environment so we can run them anywhere. And this is basically for you to let you know that if you have anything that is built on top of DNF, you have any tests reach out to us so we can eventually run your tests to make sure we don't break your software. Okay, let's back for the plans. For the Fedora 30, we still have plans. We want to deliver this shared metadata and download RPM. It means one download for the package kit, the DNF and marketer the DNF. And especially people who work on the workstation, I think they will love it. Also, as I mentioned, the unified code base. This is the target Fedora 32. And it means new stable API, new SWIG bindings. And additionally, there is the downside probably for the sum of the users. We want to drop the whole CA stack package because it will be replaced by the new stable and supported API. This actually looks quite simple, but we need to redesign quite a lot of stuff under hood without making any bigger changes in public interfaces and without breaking anything. So this will probably take some time, but the goal is to have single unified library. And the future vision. This is just an overview. We have touched these topics in the previous slides. So we are aiming to have all the business logic moved from DNF to LibDNF. So DNF stays as a compatible API with existing tools. But all the business logic will go to LibDNF, so it's available to MicroDNF and PackageKit, possibly other software. MicroDNF will gain more features. So basically, you won't see any difference if you use DNF or MicroDNF. The only thing we know about that is not achievable in MicroDNF is obviously the Python plugins. But everything else should be most likely doable in MicroDNF. And it's not going to replace DNF. We will maintain both at least for some time. And we are also thinking this is, you know, something, nothing more than a vision that we may create a DNF daemon replacing possibly the existing Python DNF daemon in Fedora, which is the back end for the DNF daegora. And we may also integrate this daemon with Anaconda, which helps them to avoid forking the DNF process and handling everything by themselves. So we can offer them a service eventually. And again, it's not going to replace anything else in the stack. It's an additional service you can use. But if you don't want to, you don't have to. And this is the final slide. So thanks to the DNF team who actually helped us to get here and made all the hard work over the last years. Also to the community and contributors who reported all the issues and bugs. And special thanks to Neil Gompah. Some of you know this guy. He actually spread DNF into three other distributions. So definitely big thanks for doing that. So this is time for questions and answers. Do you have any questions for us? Okay. DNF update info takes quite a long time to execute. Which Fedora was that? Was that 29? So, okay, we will look into that. It's related to the security filters. We have tested that. And it seemed to be working fine. Maybe if you could drop a bugzilla for us so we can reproduce that on some data or something. Or maybe if you can share the expectations with us through bugzilla, that will be really helpful. Yes. But you know, the thing is that we typically, we are not optimizing everything. If something doesn't work as expected, then we analyze that and fix that. So basically based on any reports, we can, you know, we probably need just the command and the environment. And we will look at exactly the versions we need. And especially this guy is interested in that. He does all the optimizations. I love it. Okay. The question is whether the LibDNF work will impact the size of containers. I think the answer is no. Besides, maybe the microDNF binary will slightly grow. But I don't expect anything else because all other functionality is in LibDNF already. So I don't expect any big changes in the size. And eventually you will get a fully functional DNF in the container with no additional overhead. And you're the guy who actually helped me to fix all the issues with software database. Yes, that is the goal. But we need a couple years to get there because if you look into the sources and you see all the possible code paths, it's not nice. And we want to have a single code path for everything and all everything documented. The question is whether we will have any documentation. The answer is yes. Any other question? So that's it. Thank you for attending. Thank you very much.