 Okay. Well, my name is Jaroslav Mraček and I would like to present some news about DNA5 project. First of all, I would like to thank Altarizer to give me that opportunity to share our progress with DNA5. And well... Nice progress. Yeah, okay. Well, what you will hear. The first I would like to provide some introduction. Then there will be section related to the DNA5 features and the last part will be Fedora release plan. And I hope you will enjoy it. Well, the first slide is quite simple and I think you already heard at least few of these components. DNA5 as a software management tool from the command line. MicroDNF, this is the light version of the DNA5, mostly suitable for the containers and package kit. Package kit, maybe you don't know it, but maybe you use it when you use the GNOME software. Yeah, this is the back end for the GNOME software for the RPMs or even for the other content. Well, it looks quite simple. All of these three applications has one library, LibDNF. But let me just look inside what is there and maybe you will be surprised. Because LibDNF is not one library, originally it was two libraries. It was the library for the package kit and the whole kit. That's DNF library, see library for the handling, solving and so on. Therefore, these two libraries have been merged into one envelope. Of course, when such things happen, what's the plan? Merge everything internally. It's a good plan and we start to do. We move as much of the logic that was possible from the DNF to the LibDNF library and also we try to merge internals. But then, well, what usually happens? Compatibility. I mean, you cannot change many, many things in the workflows, in the behaviors. Because more and more application depends on you and each change in the behavior and in the interface or API means breakages. As you can also see, plugins. Plugins is one of the examples of this issue. DNF has its own Python plugins. And there is also plugins for the LibDNF. Why? Why do we have two sets of the plugins? The answer is quite simple. There is very low intersection between DNF and part that is used by the package. There are some overlaps, but not many. And plugins has access to everything in the DNF. Also, plugins for the LibDNF have access to the repository configuration and so on. But each of the parts stores in the different structure. Informations that are stored in the Python, classes and so on are not accessible by the C code. Therefore, you can do whatever you like, but you cannot share these stuff. Therefore, there is no way how to have one plugin that will work for the DNF and also for the package key. With this structure, also you can be sure that if you have some issues with, for example, micro-DNF, this issue will be more likely reproducible with the package key than with the DNF because of the code duplicities. What we can do in such a situation? Well, we can start with, let's say, breaking API. It means to announce that we are not going to support the same API that we are going to change. In this case, it opens also the room for the additional changes. Like you have a minimal set I need, you want to share something, then okay, well, it will be not compatible anymore than okay. Well, let's improve it a little bit more because it will provide more value to our users. It means API users, command line users, and I think if we are going to break something, it means let's use it fully. Well, let's start to talk about the DNF5 components. As you can see, I tried to split the DNF5 components into three parts. The first part is the DNF5. DNF5 is a replacement or will be replacement of the DNF and micro-DNF. Okay, this is two different tools. They are based one on the Python. The second one is written in C with the chili. And right now there is a replacement. Also, the command line interface is similar but the same one. Therefore, even from this, we cannot promise the 100% compatibility with the DNF or the micro-DNF because we are going to replace multiple tools. What's the benefit of the replacement? DNF5 is written in C++. Therefore, we don't need a Python binding. Well, Python is a nice language, but if you need to install it, well, it requires a bit more space. It means that micro-DNF was designed for the container. Why? Well, we have a DNF. It's much more powerful because we need a smaller size. Installed size of the micro-DNF is 115 megabytes or something like that without the dependencies and so on. Installed size of the DNF is 165. It's significant difference. And with the new DNF5, we will have the same footprint. Like a micro-DNF, but we will try to provide the same set of the functionality with the DNF. Therefore, it's win-win situation. We have the same set of the functionality, but with a smaller install size. DNF-Demon. Why we have a DNF-Demon? Why we plan a DNF-Demon? Because we already have a package kit. Everyone is happy. No, but that's another story. Because DNF5-Demon will provide them more features. The package kit is unable to handle comms groups, modules, because it is not important for them. But there are other components that require to handle also the comms group and the modules. Therefore, this is opportunity how to fill the gap. It will also replace DNF-Demon. DNF-Demon is a demon written on top of DNF. It means it is Python application. And the new DNF-Demon will be small, because it will not require Python. And as you can see for the DNF5 and the DNF-Demon, they will share the DNF5 plugins. It means one plugin to everyone. It will provide the same behavior. It will provide the same set of the features with only one plugin. For win-win situation, I guess. The last thing is the library. The library, as I already mentioned, will provide the plugin interface. And also it will provide the bindings for the multiple languages. Not only Python, like we have right in our stack, but also we plan to provide additional bindings to other languages. But it depends on the requirements and on the support from the community. Because I can be honest, well, I'm not familiar with Ruby and Parallel. Therefore, we can provide the bindings, but we don't know how to test it even. Therefore, well, if there is anyone who has an interest with additional bindings, please reach us and we will be happy to cooperate and to provide bindings if there will be requirements. Features. Features of the DNF5. I already mentioned, OK, that we have a plan to provide lightweight tools that will have, let's say, footprint like micro-DNF with the same feature set like DNF. Well, another story is fully integrated on modularity in DNF5 workflows. Well, that's maybe surprising because modularity is supporting... There is a support in DNF, in read DNF, in package gain. Why it is not integrated? Well, the modularity requires huge changes in how these new content must be processed. Therefore, it is there, but this is just like addition to the original workflows. Therefore, with the current API, you can do things incorrectly. That's not good, and usually you realize it not easily because you start to install, for example, packages from the former modules that are not available anymore and so on. Therefore, this is the place for the improvements to have modularity fully integrated in our workflows. Another message, modularity will still stay in Fedora. It is important part and there are users. Therefore, we must integrate it because users... Well, the next part, the next new part is DNF Demon. As I said, support of the COMs groups and modules. The next part is a safer API. What it means? Let me use two examples. The first example is related to the configuration. DNF, any time, any plugin can modify configuration. That sounds good, but it can also modify the configuration, which is not anymore important. For example, one of the important filesetting installed. It means where you have to work. Well, you can modify it even after everything is locked. Therefore, well, you will see the setting, but you will use the different location because it was already applied that setting. In DNF 5, after some configuration is used and doesn't make sense to change it because it will not affect the original setting that was used for some process, it will get locked. It means you can easily get information that you as an API user, as a programmer, you did something incorrectly and sooner you get a message, sooner you can fix it. Otherwise, you think that everything is correct and unfortunately, well, your new setting is not applied anymore because you have changes into incorrect time. Another part is related to modules. As I said, modules are not fully integrated in DNF 4. There is a support, but if you will request changes in the modules in incorrect time, then you will not get expected results, like from the DNF. It means everything, if it's processed into one transaction process, then internals of the new library will ensure that everything is performed correctly. Okay, the next part. Performance improvements. Let's start with loading of repositories. In DNF 4, okay, once again, well, in DNF 4, what you can see from the interface, yeah, DNF starts to load a repository, yeah, you see the progress bar, at the end you see, yeah, some time it waits, no one knows what it is, that's what we know. Yeah, it protests the downloaded metadata and it converts the XML to the format that is understandable and accessible by server, and then another repository. In the DNF 5, we download the repository and when the download of the first repository finishes, we continue with the downloading of the second repository and the processing of the metadata is performed in another transaction. It's also good because both processes do not fight for the same resources. Download doesn't require much of CPU and the conversion is very heavily required, there is a heavy requirement for the CPU. Therefore, we use more efficiently resources in the short time, that's good. More repositories, more benefit. Well, I also would like to provide some example from the command line interface. The first example is with a repo query, with one argument, and mostly the first example is, as a, let's say, background test. It's quite similar, but if we will use more arguments with the DNF 5, you see the significant difference in required time. It means each of the requests, each of the query for the argument requires shorter time. Another example with the upgrade command. Again, with more arguments, you see a significant difference. No one says that no one will use it, but there are tools that use a lot of queries, like infrastructure with the DNF, and they will see the difference. This is not what normal users do, it's correct, but I just tried to use a general example, visibly even from the command line set. You can try to test and you can see the difference. Well, another important feature is the integration of the plugins into DNF 5. You will be quite surprised how often it happens that, you know, usually a third-party team, third-party plugins are usually written in Python, and everyone say, okay, to DNF, that's the main software management tool in Fedora, RHEL, and so on. Well, later on, most of these teams are surprised, because package con, package kit does not reflect these changes. Okay, it's not visible from the first time, but the sharing of the plugin and unifying behavior in our environment, that's a huge benefit. It's usually overlooked because people think that, you know, the package kit doesn't require this and then and so on. Later on, most of the people find out that, okay, well, it's not true. Some plugins, for example, modify paths for the repository to improve performance in some environments, to modify variables or to log processes externally, for example. And then they discover later on that, well, there is a gap. Someone does hear something and you don't know why, what, or it doesn't work, because simply the plugin is only applied for the DNF. Well, it is like that. Well, outputs also, we will improve the outputs. And in this case, we can say that DNF 5 is more, more similar with the information provided with microDNs at the DNF, because in this example, we also track the original changes or original version of the package. Why it is so important? Some users probably check whether the jump between the versions during the upgrade is a small one. For example, if the only, you know, the really stuck change, okay, you usually don't expect much changes. Rather than you see, okay, the major version of the component change well, that's the art. Well, something maybe is changed or then I can look for the change log. Therefore, the version sometimes provides more attention for some users that they feel it is quite important. Okay, let's jump to the next part of my presentation. And it is a release plan for the Fedora. Well, our first release is planned for the Fedora 38. Well, I know that we are now in the process of the Fedora 37, but you know, ROHAE is alive. It means Fedora 38 is alive. What we want to do? We want to release the DNF 5, and at the same time, we would like to absolve it, microDNF. Okay, don't be scared. MicroDNF will be still present in the repository, but there will be obsolete. Therefore, we will try to replace the microDNF to ensure that our stack is available to the users that want to test. Also, to make minimal damages to the Fedora. You know, this new component, we have good CI, many tests and so on, but be sure, users are very, very clever and uses very rare cases and they are only guys that prove that your component work. Therefore, it will replace in container. MicroDNF will be replaced in containers. It will be available. Library will be available. Therefore, people who want to, for example, start with the building of the plugins and so on, they have the possibility to test. And of course, if it's released, then, you know, it's much more easier to... It's much more easier for the community to start to interact with the project. Okay, there will be a compatibility. I don't say one other compatibility because as I said, in future, DNF will replace not only microDNF, but also DNF. And there are differences and we also want to, you know, get rid of some historical things like some aliases that no one use, compounds that are not used and so on. Therefore, well, expect changes. But if you don't like, don't hesitate to contact us. Vaxilla or any other tool, which you are so who cares, is a good place to put your requirements. Well, and not only... We will not provide only... Not only microDNF siblings, but commands and most of the options of the microDNF. Not many. Therefore, we have not much to do. Therefore, we will release more. We will release more functionality. Some functionality, for example, that is not from the DNF. Well, release brokers. Why we don't have a DNF 5 in Rohit right now is because modularity, yeah, it's not yet fully implemented and also internal history DB. Both of the things are critical. The first one to ensure that people will see the same behavior like with the DNF when the modules will be enabled. Therefore, it's critical. The same changes in the layer where we store some internals. It's, again, quite difficult to do it during the time because you need to combat from one version to another one and if you do it twice or third time during the short period, well, that's how. Okay, the next plans. Fedora 39. And we would like to present a DNF 5 as a main software management tool for the Fedora 39. What it means? It means that we have to somehow replace a DNF and in such a case, we, again, need to provide a compatibility because, well, we should not force people to, let's say, learn new binaries as it must be called. Let's use a DNF still. DNF, micro-DNF and DNF 5. Everything will work. But, again, there will be not a 30% compatibility. We will try as much as possible to support the common use of cases. The most used commands and the options. But there will be changes. DNF 5 is not a DNF. It's a different tool. And as you can see, well, there is a proposal for the Fedora 39 change. Okay, it's not yet applied but I will do it quite soon. Therefore, you can visit the page. Well, let's jump to the, well, if I'm here, I can also introduce a DNF team. Well, the first on the list is Alish Matyei. Alish Matyei is the expert for the Cray Triposy and also he implemented a part related to the Advisories to the DNF 5. Next is Jan Kolarik. Jan Kolarik is our new DNF member. Therefore, we welcome him and we hope that he will enjoy the stay in the team. Well, this guy is me. Well, I am a team lead and also I participate on the development of the RPM queries or the stuff related to the lip solve. Yaroslav Ruhel, well, he's the guy who implemented in DNF 5 comms groups, RPM transactions. No, sorry, not comms groups. Configurations, repositories and RPM transactions. Lukasz Rasky, he's the guy who is developing the history DB and the system state and Marek Balagha, he's leading the development of the DNF 5 demon. Nikola, he also participates on the development of the demon and the last but not least, Pavel Kartochilov. Well, he implemented comms group, she's now working on the implementation of the modules and other stuff. Well, here are some links for the upstream repository. Our upstream repository contains all three major components. This means the DNF 5, DNF 5, DNF 5 demon. Also, we have a copy repository with unstable RPMs. I'm saying unstable because please don't use it for the production. It's been up to you. And also we have a documentation for the DNF 5 demon. And that's it. That's all from my side. Thank you very much for the listen. Any questions? Go on. What's the purpose of the DNF demon client command, like regarding comparing to micro DNF and DNF itself? Well, DNF demon provides D-Bus interface. Therefore, you can use any language that you like. You send a message over D-Bus and we receive and we process. That's the purpose. So you just reprobated D-Bus. Yeah, well, that's... Yeah, it's not reprobated. I mean, we provide the server side and D-Bus is the only channel how to communicate with the other side of the client. We also have some testing client, but it's expected... So it's not supposed to be used by a normal user? No. But even for the testing, we need to provide a client like the package.com for the package kit because this is the only way how can easily reproduce something that happens over the D-Bus. Thank you. You're welcome. Any other questions? Go on. Will there be a difference of the level of the API between LibDNF and the D-Bus demon? Let's say I want to install a package. Will there be a D-Bus method install package and then will the library have a function called install package? Or will there be a difference between the level of access to the details, let's say? Well, it's a good question. Well, first of all, we can expose most of the functionality through the D-Bus. Of course, the names, I mean, the messages will be called slightly different, but the functionality can be exposed. What's the problem with the D-Bus? I mean, transferring of the huge data. I mean, you will have to somehow pack, somehow send it, somehow, you know, unsend it, therefore, you cannot transfer the structures. But if you say, well, most of the things can be achieved using the demon as well from the API. Depends on the, let's say, requirements. There are some limits, but if there will be, let's say, a requirement to expose something, I mean, you cannot blindly, you cannot, anything what we will support on the server side, well, then we can, if there will be a requirement from the D-Bus user to expose something, we can add it. But of course, it doesn't work in reverse. Everything but is an API, it's directly accessible through to D-Bus. Did I answer your question? Yeah, I was more asking about the level because I know that using Hockey and the Python API for DNF, and using the DNF as a common line tool is completely different. There is no, like you do DNF install Emacs, but you don't have a single function in the API to install Emacs, like, which would be like install and one string, or yeah, like a... Actually, we have it in DNF for in the Python part. There is a function that works like that. It is not part of the Hockey. Yeah, but will it be in LibDNF5? Yeah, sure. It is there because as I said, we try to move as much functionality from the library because this is the only way how to share as much as possible. We are lazy guys, you know, we don't want to write things twice. This is good. Anyway, some level flies us. Any other questions? Go on. I want to say that I used the Hockey DNF and I went back and it just seems to work already nicely, so I think it's usable. It's not really experimental, you can just install it. You mean DNF5 or DNF? Yes, DNF5. Well, it's experimental because there is no support of the modules. Therefore, you know, the modules are part of the REL and Fedora. I'm not saying that it is by default enabled, but the users that use modules, they will get in trouble without the support of the modules because the next upgrade will change the versions in unwanted versions and, well, let's say call it freely, it will be disastrous. And that's why we have to wait until the rudimentary support of the modules will be present in the library. That's the one very, very critical point for the REL because we are on the level where we cannot guess. We should predict all possibilities in advance because we like our users and then hopefully they like us or at least not hate. Thank you. Anyway, I hope that in let's say one month there will be a release but it's roughly glass and, of course, if the release will not appear before the Christmas, I think the fesco will start to complain. Be sure. Plans are plans. That's any other question? Well, anyway, time is already over, I guess.