Re: Announcing start of DNF 5 development
On Mon, Apr 6, 2020 at 8:08 PM Adam Williamson wrote: > > On Mon, 2020-04-06 at 23:56 +, Tom Seewald wrote: > > Yep, I just ran "dnf info kernel" and then right after that "dnf > > changelog kernel", in both cases dnf spent over 20 seconds syncing. > > I haven't seen other package managers require this much network > > traffic, and I wonder if a lot of it could be avoided. > > If you only want to query *locally installed* packages, you can just > use rpm: > > rpm -qi kernel > rpm -q --changelog kernel > > if you use DNF, it will get the info for packages that are in the > repositories but not locally installed, as well. changelogs are kept > and retrieved separately, I believe, as they aren't needed for any > other operations, so that's why you see remote trips on both commands, > I think. With the exception of changelogs (which requires downloading other.xml metadata), all query actions should be possible to perform with DNF with --cacheonly flag, which will use the system cache or local user cache if it hasn't expired yet. I have heard from people that the cache is expiring prematurely in some cases (thus forcing more metadata downloads), but I haven't been able to reproduce it myself. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Announcing start of DNF 5 development
On Mon, 2020-04-06 at 23:56 +, Tom Seewald wrote: > Yep, I just ran "dnf info kernel" and then right after that "dnf > changelog kernel", in both cases dnf spent over 20 seconds syncing. > I haven't seen other package managers require this much network > traffic, and I wonder if a lot of it could be avoided. If you only want to query *locally installed* packages, you can just use rpm: rpm -qi kernel rpm -q --changelog kernel if you use DNF, it will get the info for packages that are in the repositories but not locally installed, as well. changelogs are kept and retrieved separately, I believe, as they aren't needed for any other operations, so that's why you see remote trips on both commands, I think. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Announcing start of DNF 5 development
Yep, I just ran "dnf info kernel" and then right after that "dnf changelog kernel", in both cases dnf spent over 20 seconds syncing. I haven't seen other package managers require this much network traffic, and I wonder if a lot of it could be avoided. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Announcing start of DNF 5 development
On Fri, Mar 13, 2020 at 12:23 PM Pat Riehecky wrote: > > On Fri, Mar 13, 2020 at 9:48 AM Robbie Harwood wrote: > > > > Daniel Mach writes: > > > > > Dne 12. 03. 20 v 19:26 Pat Riehecky napsal(a): > > > > > >> I realize I'm thinking about the Pie in the Sky, but: > > >> > > >> Would it be possible for 'microdnf' to become the base for 'dnf' so > > >> that extra 'dnf' functionality is added via some kind of > > >> modules/plugins/etc behaviour? Perhaps "somehow" it could (for > > >> example) find out "oh I've got python, lets load those feature bits > > >> too". > > >> > > >> This could help keep them fully compatible and let folks using dnf > > >> based installers look at pulling in just the features they require. > > > > > > I don't think we're ready for this yet. We need to work on improving > > > libdnf and delivering a dbus interface in the first place as > > > announced. Once we're finished with these changes, we'll definitely > > > look into making python optional. > > > > This confuses me. microdnf works today. This means that python is > > *already* optional. > > > > I believe what's being suggested is to stop duplicating microdnf > > functionality in python. That way reduces code duplication, which means > > there's less to maintain, test functionality between, etc.. > > > > Pat has suggested a particular way this might be accomplished (module > > detection with a module providing python capability), but the details of > > this strike me as less important than having fewer package managers. > > > > Thanks, > > --Robbie > > That is what I attempted to suggest (though worded better). > The problem is that MicroDNF barely works like DNF does today in terms of basic operations, and is architecturally not structured to support becoming the main "core" of the DNF package manager frontend. Moreover, it does not present output in the same way that the main DNF frontend does, nor does it handle options the same way. A lot of how MicroDNF works will need to change to become the core of a new DNF frontend, essentially mandating a rewrite of the application. A rewrite is already planned, but making a rewritten version of MicroDNF available is not planned anytime soon. The existing MicroDNF works with libdnf from the DNF 4 stack, and that will stay basically the same while the DNF 5 stack is being developed. With everything else going on as part of the DNF 5 development, I do not think this will be possible to change this unless there's more developers to help with making that transition possible. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Announcing start of DNF 5 development
On Fri, Mar 13, 2020 at 9:48 AM Robbie Harwood wrote: > > Daniel Mach writes: > > > Dne 12. 03. 20 v 19:26 Pat Riehecky napsal(a): > > > >> I realize I'm thinking about the Pie in the Sky, but: > >> > >> Would it be possible for 'microdnf' to become the base for 'dnf' so > >> that extra 'dnf' functionality is added via some kind of > >> modules/plugins/etc behaviour? Perhaps "somehow" it could (for > >> example) find out "oh I've got python, lets load those feature bits > >> too". > >> > >> This could help keep them fully compatible and let folks using dnf > >> based installers look at pulling in just the features they require. > > > > I don't think we're ready for this yet. We need to work on improving > > libdnf and delivering a dbus interface in the first place as > > announced. Once we're finished with these changes, we'll definitely > > look into making python optional. > > This confuses me. microdnf works today. This means that python is > *already* optional. > > I believe what's being suggested is to stop duplicating microdnf > functionality in python. That way reduces code duplication, which means > there's less to maintain, test functionality between, etc.. > > Pat has suggested a particular way this might be accomplished (module > detection with a module providing python capability), but the details of > this strike me as less important than having fewer package managers. > > Thanks, > --Robbie That is what I attempted to suggest (though worded better). -- The lines which your eye falls on first here were written last. Their purpose is to make yet another attempt to force into the form of a letter the detailed investigation which is sent to you herewith. These lines correspond, then, with the last lines and together they form an envelope, thus indicating in an external way what internal proofs in many ways will convince you of, that this is a letter you are reading. ~Kierkegaard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Announcing start of DNF 5 development
Daniel Mach writes: > Dne 12. 03. 20 v 19:26 Pat Riehecky napsal(a): > >> I realize I'm thinking about the Pie in the Sky, but: >> >> Would it be possible for 'microdnf' to become the base for 'dnf' so >> that extra 'dnf' functionality is added via some kind of >> modules/plugins/etc behaviour? Perhaps "somehow" it could (for >> example) find out "oh I've got python, lets load those feature bits >> too". >> >> This could help keep them fully compatible and let folks using dnf >> based installers look at pulling in just the features they require. > > I don't think we're ready for this yet. We need to work on improving > libdnf and delivering a dbus interface in the first place as > announced. Once we're finished with these changes, we'll definitely > look into making python optional. This confuses me. microdnf works today. This means that python is *already* optional. I believe what's being suggested is to stop duplicating microdnf functionality in python. That way reduces code duplication, which means there's less to maintain, test functionality between, etc.. Pat has suggested a particular way this might be accomplished (module detection with a module providing python capability), but the details of this strike me as less important than having fewer package managers. Thanks, --Robbie signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Announcing start of DNF 5 development
Dne 12. 03. 20 v 19:26 Pat Riehecky napsal(a): I realize I'm thinking about the Pie in the Sky, but: Would it be possible for 'microdnf' to become the base for 'dnf' so that extra 'dnf' functionality is added via some kind of modules/plugins/etc behaviour? Perhaps "somehow" it could (for example) find out "oh I've got python, lets load those feature bits too". This could help keep them fully compatible and let folks using dnf based installers look at pulling in just the features they require. I don't think we're ready for this yet. We need to work on improving libdnf and delivering a dbus interface in the first place as announced. Once we're finished with these changes, we'll definitely look into making python optional. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
RE: Announcing start of DNF 5 development
I realize I'm thinking about the Pie in the Sky, but: Would it be possible for 'microdnf' to become the base for 'dnf' so that extra 'dnf' functionality is added via some kind of modules/plugins/etc behaviour? Perhaps "somehow" it could (for example) find out "oh I've got python, lets load those feature bits too". This could help keep them fully compatible and let folks using dnf based installers look at pulling in just the features they require. -- The lines which your eye falls on first here were written last. Their purpose is to make yet another attempt to force into the form of a letter the detailed investigation which is sent to you herewith. These lines correspond, then, with the last lines and together they form an envelope, thus indicating in an external way what internal proofs in many ways will convince you of, that this is a letter you are reading. ~Kierkegaard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Announcing start of DNF 5 development
On Thu, Mar 12, 2020 at 08:22:48AM +0100, Daniel Mach wrote: > > > Dne 12. 03. 20 v 6:21 Chris Murphy napsal(a): > >On Thu, Mar 5, 2020 at 8:30 AM Daniel Mach wrote: > >> > >> > >> > >>Dne 04. 03. 20 v 23:01 Neal Gompa napsal(a): > >>>On Wed, Mar 4, 2020 at 4:37 PM Zbigniew Jędrzejewski-Szmek > >>> wrote: > Are you going to use sd-bus for the dbus library? > > >>> > >>>I'd hope not, given that we have cross-distro usage of DNF now, and a > >>>couple of them don't have systemd. > >>> > >>Do you know which distros do not have systemd? > >> > >>We have evaluated sd-bus to be the best dbus client available, but we > >>may have underestimated it's adoption. > >> > >>Couldn't systemd team split it into a separate library independent on > >>the rest of the systemd eco-system? :) > > > >Is varlink applicable here? I mention it because I've come across it > >being used by systemd-homed. It's intended to be available during > >early boot. > > > > We have considered both dbus and varlink and decided to use dbus. > Dbus has better adoption and we'll be replacing a dbus service > (PackageKit) with another. varlink is useful for cases where dbus is not available — early boot, or as part of the supporting infra for the dbus broker daemon itself. dbus is the preferred solution for the case where we want to expose a service to many client, have unprivileged clients communicating with a system daemon, and possibly do privilege escalation using polkit. dbus seems very much to be the right choice for dnf. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Announcing start of DNF 5 development
Dne 12. 03. 20 v 6:21 Chris Murphy napsal(a): On Thu, Mar 5, 2020 at 8:30 AM Daniel Mach wrote: Dne 04. 03. 20 v 23:01 Neal Gompa napsal(a): On Wed, Mar 4, 2020 at 4:37 PM Zbigniew Jędrzejewski-Szmek wrote: Are you going to use sd-bus for the dbus library? I'd hope not, given that we have cross-distro usage of DNF now, and a couple of them don't have systemd. Do you know which distros do not have systemd? We have evaluated sd-bus to be the best dbus client available, but we may have underestimated it's adoption. Couldn't systemd team split it into a separate library independent on the rest of the systemd eco-system? :) Is varlink applicable here? I mention it because I've come across it being used by systemd-homed. It's intended to be available during early boot. We have considered both dbus and varlink and decided to use dbus. Dbus has better adoption and we'll be replacing a dbus service (PackageKit) with another. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Announcing start of DNF 5 development
On Thu, Mar 5, 2020 at 8:30 AM Daniel Mach wrote: > > > > Dne 04. 03. 20 v 23:01 Neal Gompa napsal(a): > > On Wed, Mar 4, 2020 at 4:37 PM Zbigniew Jędrzejewski-Szmek > > wrote: > >> Are you going to use sd-bus for the dbus library? > >> > > > > I'd hope not, given that we have cross-distro usage of DNF now, and a > > couple of them don't have systemd. > > > Do you know which distros do not have systemd? > > We have evaluated sd-bus to be the best dbus client available, but we > may have underestimated it's adoption. > > Couldn't systemd team split it into a separate library independent on > the rest of the systemd eco-system? :) Is varlink applicable here? I mention it because I've come across it being used by systemd-homed. It's intended to be available during early boot. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Announcing start of DNF 5 development
> > Hello everyone, > > I'm pleased to announce start of DNF 5 development. We are planning to > > deliver a module stream or a COPR repo during Fedora 33 development for > > early adopters and tool developers and we're hoping in getting a stable > > version into Fedora 34. > > > > Can it be: > 1. faster > 2. have a better dnf history (like one we could interact with) > > > Also I still don't understand why my dnf redownloads the repolist almost > everytime I use it for a search. I thought thiswas supposed to be fixed with > delta repo or zchunk something. This past is the really slow one. It also regularly downloads the entire cache again even if the cache is not very old. Things like a "dnf repoquery --whatrequires" pretty much is guaranteed to re-dowload the cache again even if a repoquery commands was only run a few minutes earlier. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Announcing start of DNF 5 development
On Wednesday, 4 March 2020 19:03:01 CET Daniel Mach wrote: > Hello everyone, > I'm pleased to announce start of DNF 5 development. We are planning to > deliver a module stream or a COPR repo during Fedora 33 development for > early adopters and tool developers and we're hoping in getting a stable > version into Fedora 34. > Can it be: 1. faster 2. have a better dnf history (like one we could interact with) Also I still don't understand why my dnf redownloads the repolist almost everytime I use it for a search. I thought thiswas supposed to be fixed with delta repo or zchunk something. This past is the really slow one. Best regards, Robert-André ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Announcing start of DNF 5 development
On Fri, Mar 6, 2020 at 10:06 AM Stephen John Smoogen wrote: > On Fri, 6 Mar 2020 at 11:42, Marcin Juszkiewicz > wrote: >> I have never understood a need for per-user copy of repo metadata. > > > I am remembering that attempts to do this with either yum or dnf did not go > over well with the community as a whole. To make it work, the cache has to be > either constantly polling or be able to be triggered by the user to keep up > to date. Every hour it's updated by dnf makecache, which only updates the one in /var/cache/dnf, not the one in /var/tmp if the user has their own. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Announcing start of DNF 5 development
On 3/5/20 2:08 PM, Daniel Mach wrote: I hope that someday we'll get microdnf close to 100% feature parity with DNF (Python plugins excluding obviously) Great plan, but when it happens, could it also get a simple IPC to talk to the optional Python plugins, and thus replace dnf entirely? What is the intended differentiation between dnf and microdnf design goals? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Announcing start of DNF 5 development
On Fri, 6 Mar 2020 at 11:42, Marcin Juszkiewicz wrote: > W dniu 06.03.2020 o 02:57, Neal Gompa pisze: > > The database has been synchronized since Fedora 24. However, the > > caches are not, and that *does* need to be fixed. > > And when user calls dnf let it use system cache by default... > > > > I have never understood a need for per-user copy of repo metadata. > I am remembering that attempts to do this with either yum or dnf did not go over well with the community as a whole. To make it work, the cache has to be either constantly polling or be able to be triggered by the user to keep up to date. Having it running all the time got complaints about memory and cpu usage. Letting the user trigger this allowed for various bad actor/troll ways of polluting the cache with bad data that affected everyone. Having a daemon which runs to keep things up to date was considered wasteful for resources (why is dnfd sitting in the background at 2GB of ram??). Next there is always the person who wants to cache stuff outside of what is system on. If you are on a F31 box and need to develop against F33 and F32, then the system has to cache all of those. If you have it just caching for the user defined ones.. you might as well have it cache for F31 also at the user level as the speed for doing that is not much different. Finally there are the people who expect it to work that way for whatever tool they have and not doing it that way breaks their carefully worked out workflows. -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Announcing start of DNF 5 development
W dniu 06.03.2020 o 02:57, Neal Gompa pisze: > The database has been synchronized since Fedora 24. However, the > caches are not, and that *does* need to be fixed. And when user calls dnf let it use system cache by default... 17:38 (0s) hrw@puchatek:~$ time sudo dnf info nano [ fetching all repo data... ] Dostępne pakiety Nazwa: nano Wersja : 4.3 Wydanie : 3.fc31 Architektura : x86_64 Rozmiar : 640 k Źródło : nano-4.3-3.fc31.src.rpm Repozytorium : updates Podsumowanie : A small text editor Adres URL: https://www.nano-editor.org Licencja : GPLv3+ Opis : GNU nano is a small and friendly text editor. real0m49,066s user0m21,141s sys 0m1,131s 17:38 (49s) hrw@puchatek:~$ time sudo dnf info nano Ostatnio sprawdzono ważność metadanych: 0:00:09 temu w dniu pią, 6 mar 2020, 17:38:55. Dostępne pakiety Nazwa: nano Wersja : 4.3 Wydanie : 3.fc31 Architektura : x86_64 Rozmiar : 640 k Źródło : nano-4.3-3.fc31.src.rpm Repozytorium : updates Podsumowanie : A small text editor Adres URL: https://www.nano-editor.org Licencja : GPLv3+ Opis : GNU nano is a small and friendly text editor. real0m1,542s user0m1,368s sys 0m0,142s 17:39 (2s) hrw@puchatek:~$ time dnf info nano [ fetching all repo data... ] Dostępne pakiety Nazwa: nano Wersja : 4.3 Wydanie : 3.fc31 Architektura : x86_64 Rozmiar : 640 k Źródło : nano-4.3-3.fc31.src.rpm Repozytorium : updates Podsumowanie : A small text editor Adres URL: https://www.nano-editor.org Licencja : GPLv3+ Opis : GNU nano is a small and friendly text editor. real0m56,689s user0m21,374s sys 0m1,130s 17:40 (57s) hrw@puchatek:~$ I have never understood a need for per-user copy of repo metadata. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Announcing start of DNF 5 development
On Thursday, 5 March 2020 21.11.37 WET Adam Williamson wrote: > I mean, it shouldn't be too hard to standardize on having them all work > both ways, even. I agree with Adam. What would be the drawback from this change? It is backwards compatible (an important issue in this context). And there are other cases like: --enable, --set-enabled according to the documentation those are synonyms. -- José Abílio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Announcing start of DNF 5 development
On Thu, 5 Mar 2020 20:08:17 +0100 Daniel Mach wrote: > Dne 05. 03. 20 v 13:02 Marcin Juszkiewicz napsal(a): > > W dniu 04.03.2020 o 19:03, Daniel Mach pisze: > > Are there plans for picodnf then? Or cutting amount of > > libraries used by microdnf? > > I don't think we can drop more without losing functionality. > If you take a closer look, libdnf links to libcurl which pulls most > of the dependencies. In an environment where size matters a lot, you could use curl-minimal and libcurl-minimal instead of curl and libcurl, which pull in fewer dependencies. Paul. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Announcing start of DNF 5 development
On Fri, 6 Mar 2020 at 01:59, Neal Gompa wrote: > caches are not, and that *does* need to be fixed. The library > interface for DNF already has APIs for this, PackageKit doesn't use > them. I'm 100% okay with a pull request to fix this, as long as the same cache promises are met, i.e. PackageKit never downloads an incomplete set of metadata and does an atomic swap. Richard. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Announcing start of DNF 5 development
On Thu, Mar 5, 2020 at 8:51 PM Luya Tshimbalanga wrote: > > > We've managed to drop a lot of redundant code across the whole DNF stack > > in the past years, but we have reached a point when it's nearly > > impossible to consolidate the code any further without breaking the > > API/ABI. Especially with PackageKit being dead[1], we can't move with > > the old "libhif" API in libdnf, because making any bigger changes to > > PackageKit is clearly out of scope. > > > > [1] > > https://blogs.gnome.org/hughsie/2019/02/14/packagekit-is-dead-long-live-w... > > > > *Ahem* See the comments on the above links an the github is still active > https://github.com/hughsie/PackageKit > > The main issue related to PackageKit linked libdnf was the lack of > synchronization of the database. PackageKit was made to be cross-platform for > distributions with minimum reliance on specific distribution command, Losing > PackageKit would lead to yet another step back with multiple commands > difficult to remember thus another fragmentation. The database has been synchronized since Fedora 24. However, the caches are not, and that *does* need to be fixed. The library interface for DNF already has APIs for this, PackageKit doesn't use them. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Announcing start of DNF 5 development
> We've managed to drop a lot of redundant code across the whole DNF stack > in the past years, but we have reached a point when it's nearly > impossible to consolidate the code any further without breaking the > API/ABI. Especially with PackageKit being dead[1], we can't move with > the old "libhif" API in libdnf, because making any bigger changes to > PackageKit is clearly out of scope. > > [1] > https://blogs.gnome.org/hughsie/2019/02/14/packagekit-is-dead-long-live-w... > *Ahem* See the comments on the above links an the github is still active https://github.com/hughsie/PackageKit The main issue related to PackageKit linked libdnf was the lack of synchronization of the database. PackageKit was made to be cross-platform for distributions with minimum reliance on specific distribution command, Losing PackageKit would lead to yet another step back with multiple commands difficult to remember thus another fragmentation. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Announcing start of DNF 5 development
On Thu, 2020-03-05 at 18:38 +, J. Randall Owens wrote: > On 04/03/2020 18:03, Daniel Mach wrote: > > Hello everyone, > > I'm pleased to announce start of DNF 5 development. We are planning to > > deliver a module stream or a COPR repo during Fedora 33 development for > > early adopters and tool developers and we're hoping in getting a stable > > version into Fedora 34. > > > > > > More details follow. > > > > > > We've managed to drop a lot of redundant code across the whole DNF stack > > in the past years, but we have reached a point when it's nearly > > impossible to consolidate the code any further without breaking the > > API/ABI. Especially with PackageKit being dead[1], we can't move with > > the old "libhif" API in libdnf, because making any bigger changes to > > PackageKit is clearly out of scope. > > > > [1] > > https://blogs.gnome.org/hughsie/2019/02/14/packagekit-is-dead-long-live-well-something-else/ > > > > > > > > That's why we decided to start working on a new version of the DNF > > stack: DNF 5. And this is the plan: > > > > > > Priorities > > -- > > 1. Consistency, documentation and user experience is the top priority. > > 2. Compatibility on the command line level. > > 3. Compatibility on the API level. > > > In favour of 1., but going against 2., I've wanted since the YUM days to > see more consistency in the compound-word* options. E.g., --enablerepo > but --skip-broken, and I have a hard time remembering which ones get the > hyphen inbetween*, and which ones don't. Could we settle on one way or > the other, right now quite the majority are without hyphen, and > deprecate the other (but presumably enable both spellings for a good > long while, perhaps with a warning if someone spells it the old way)? > Probably not take away the old spellings as soon as DNF 5, but it might > be a good time to add the more consistent spellings. I mean, it shouldn't be too hard to standardize on having them all work both ways, even. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Announcing start of DNF 5 development
On Thu, 2020-03-05 at 14:08 +, Zbigniew Jędrzejewski-Szmek wrote: > > > > (OK, it's a single library with other parts included, but the sd-bus > > > part is the biggest by far, and also sd-bus uses sd-event and sd-128 > > > internally, so they'd be required anyway. The other parts are smaller, > > > and matter more because of dependencies they pull in than because of > > > the code size itself. But it is possible to compile libsystemd w/o > > > some features, notably without encryption, to save size and deps. > > > I don't think there's any significant barrier to using libsystemd > > > on non-systemd systems, except for psychological issues.) > > > > > > > Don't discount psychological issues. The original reason for DNF not > > being named YUM was so that the project would be free to do better > > without the YUM baggage. That had the added effect of making it easier > > to propose for other distributions to adopt because YUM has a very > > negative reputation outside of the RHEL space. > > ;]]] Let's just hope that the underlying ipc library is something that > is not visible to users ;) pull-request: s/libsystemd/libvoldemort/g/ -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Announcing start of DNF 5 development
Dne 05. 03. 20 v 19:38 J. Randall Owens napsal(a): On 04/03/2020 18:03, Daniel Mach wrote: Hello everyone, I'm pleased to announce start of DNF 5 development. We are planning to deliver a module stream or a COPR repo during Fedora 33 development for early adopters and tool developers and we're hoping in getting a stable version into Fedora 34. More details follow. We've managed to drop a lot of redundant code across the whole DNF stack in the past years, but we have reached a point when it's nearly impossible to consolidate the code any further without breaking the API/ABI. Especially with PackageKit being dead[1], we can't move with the old "libhif" API in libdnf, because making any bigger changes to PackageKit is clearly out of scope. [1] https://blogs.gnome.org/hughsie/2019/02/14/packagekit-is-dead-long-live-well-something-else/ That's why we decided to start working on a new version of the DNF stack: DNF 5. And this is the plan: Priorities -- 1. Consistency, documentation and user experience is the top priority. 2. Compatibility on the command line level. 3. Compatibility on the API level. In favour of 1., but going against 2., I've wanted since the YUM days to see more consistency in the compound-word* options. E.g., --enablerepo but --skip-broken, and I have a hard time remembering which ones get the hyphen inbetween*, and which ones don't. Could we settle on one way or the other, right now quite the majority are without hyphen, and deprecate the other (but presumably enable both spellings for a good long while, perhaps with a warning if someone spells it the old way)? Probably not take away the old spellings as soon as DNF 5, but it might be a good time to add the more consistent spellings. * Yes, I did that on purpose. I'll definitely put this on the list. We're primarily aiming at even worse stuff: $ dnf list bash -> displays bash package $ dnf list available -> displays all available packages $ dnf list installed -> displays all installed packages $ dnf list all -> displays all packages What if there were packages named 'all', 'available' or 'installed'? These are yum compatibility quirks which should be replaced with proper --options. There's definitely much more than this example. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Announcing start of DNF 5 development
Dne 05. 03. 20 v 13:02 Marcin Juszkiewicz napsal(a): W dniu 04.03.2020 o 19:03, Daniel Mach pisze: Hello everyone, I'm pleased to announce start of DNF 5 development. microdnf > Microdnf is becoming important because it's part of many containers due to its small footprint. [root@puchatek hrw]# ldd /bin/microdnf |wc -l 70Following deps should be going away: libglib-2.0.so.0 libgobject-2.0.so.0 libffi.so.6 libpeas-1.0.so.0 libgmodule-2.0.so.0 libgirepository-1.0.so.1 libgio-2.0.so.0 hrw@j13-qrep-04:ceph-12.2.11$ ldd /usr/bin/apt|wc -l 20 Are there plans for picodnf then? Or cutting amount of libraries used by microdnf? I don't think we can drop more without losing functionality. If you take a closer look, libdnf links to libcurl which pulls most of the dependencies. My problem with DNF is Python. There is a huge amount of packages which need to be in proper state to be able to use dnf. I remember when I did some experiments with RHEL7 and managed to get to the point where 'yum' was unable to help as Python was broken. This probably makes you one of the users we're improving microdnf for. I hope that someday we'll get microdnf close to 100% feature parity with DNF (Python plugins excluding obviously). But that's going to take a while... ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Announcing start of DNF 5 development
Also: builddep vs. build-dep ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Announcing start of DNF 5 development
On 04/03/2020 18:03, Daniel Mach wrote: > Hello everyone, > I'm pleased to announce start of DNF 5 development. We are planning to > deliver a module stream or a COPR repo during Fedora 33 development for > early adopters and tool developers and we're hoping in getting a stable > version into Fedora 34. > > > More details follow. > > > We've managed to drop a lot of redundant code across the whole DNF stack > in the past years, but we have reached a point when it's nearly > impossible to consolidate the code any further without breaking the > API/ABI. Especially with PackageKit being dead[1], we can't move with > the old "libhif" API in libdnf, because making any bigger changes to > PackageKit is clearly out of scope. > > [1] > https://blogs.gnome.org/hughsie/2019/02/14/packagekit-is-dead-long-live-well-something-else/ > > > > That's why we decided to start working on a new version of the DNF > stack: DNF 5. And this is the plan: > > > Priorities > -- > 1. Consistency, documentation and user experience is the top priority. > 2. Compatibility on the command line level. > 3. Compatibility on the API level. In favour of 1., but going against 2., I've wanted since the YUM days to see more consistency in the compound-word* options. E.g., --enablerepo but --skip-broken, and I have a hard time remembering which ones get the hyphen inbetween*, and which ones don't. Could we settle on one way or the other, right now quite the majority are without hyphen, and deprecate the other (but presumably enable both spellings for a good long while, perhaps with a warning if someone spells it the old way)? Probably not take away the old spellings as soon as DNF 5, but it might be a good time to add the more consistent spellings. * Yes, I did that on purpose. -- J. Randall Owens | http://www.GhiaPet.net/ signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Announcing start of DNF 5 development
On Thu, Mar 5, 2020 at 9:09 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Thu, Mar 05, 2020 at 09:02:47AM -0500, Neal Gompa wrote: > > On Thu, Mar 5, 2020 at 9:00 AM Zbigniew Jędrzejewski-Szmek > > wrote: > > > > > > On Thu, Mar 05, 2020 at 02:29:38PM +0100, Daniel Mach wrote: > > > > > > > > > > > > Dne 04. 03. 20 v 23:01 Neal Gompa napsal(a): > > > > >On Wed, Mar 4, 2020 at 4:37 PM Zbigniew Jędrzejewski-Szmek > > > > > wrote: > > > > >>Are you going to use sd-bus for the dbus library? > > > > >> > > > > > > > > > >I'd hope not, given that we have cross-distro usage of DNF now, and a > > > > >couple of them don't have systemd. > > > > > > > > > Do you know which distros do not have systemd? > > > > > > > > We have evaluated sd-bus to be the best dbus client available, but > > > > we may have underestimated it's adoption. > > > > > > > > Couldn't systemd team split it into a separate library independent > > > > on the rest of the systemd eco-system? :) > > > > > > It's already a separate library independent from the rest of the > > > systemd eco-system ;) > > > > > > (OK, it's a single library with other parts included, but the sd-bus > > > part is the biggest by far, and also sd-bus uses sd-event and sd-128 > > > internally, so they'd be required anyway. The other parts are smaller, > > > and matter more because of dependencies they pull in than because of > > > the code size itself. But it is possible to compile libsystemd w/o > > > some features, notably without encryption, to save size and deps. > > > I don't think there's any significant barrier to using libsystemd > > > on non-systemd systems, except for psychological issues.) > > > > > > > Don't discount psychological issues. The original reason for DNF not > > being named YUM was so that the project would be free to do better > > without the YUM baggage. That had the added effect of making it easier > > to propose for other distributions to adopt because YUM has a very > > negative reputation outside of the RHEL space. > > ;]]] Let's just hope that the underlying ipc library is something that > is not visible to users ;) > The BuildRequires: systemd-devel generally gives it away, and the failure to build because of that missing dependency is usually a problem. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Announcing start of DNF 5 development
On Thu, Mar 05, 2020 at 09:02:47AM -0500, Neal Gompa wrote: > On Thu, Mar 5, 2020 at 9:00 AM Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Thu, Mar 05, 2020 at 02:29:38PM +0100, Daniel Mach wrote: > > > > > > > > > Dne 04. 03. 20 v 23:01 Neal Gompa napsal(a): > > > >On Wed, Mar 4, 2020 at 4:37 PM Zbigniew Jędrzejewski-Szmek > > > > wrote: > > > >>Are you going to use sd-bus for the dbus library? > > > >> > > > > > > > >I'd hope not, given that we have cross-distro usage of DNF now, and a > > > >couple of them don't have systemd. > > > > > > > Do you know which distros do not have systemd? > > > > > > We have evaluated sd-bus to be the best dbus client available, but > > > we may have underestimated it's adoption. > > > > > > Couldn't systemd team split it into a separate library independent > > > on the rest of the systemd eco-system? :) > > > > It's already a separate library independent from the rest of the > > systemd eco-system ;) > > > > (OK, it's a single library with other parts included, but the sd-bus > > part is the biggest by far, and also sd-bus uses sd-event and sd-128 > > internally, so they'd be required anyway. The other parts are smaller, > > and matter more because of dependencies they pull in than because of > > the code size itself. But it is possible to compile libsystemd w/o > > some features, notably without encryption, to save size and deps. > > I don't think there's any significant barrier to using libsystemd > > on non-systemd systems, except for psychological issues.) > > > > Don't discount psychological issues. The original reason for DNF not > being named YUM was so that the project would be free to do better > without the YUM baggage. That had the added effect of making it easier > to propose for other distributions to adopt because YUM has a very > negative reputation outside of the RHEL space. ;]]] Let's just hope that the underlying ipc library is something that is not visible to users ;) Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Announcing start of DNF 5 development
On Thu, Mar 5, 2020 at 9:02 AM Josh Boyer wrote: > > On Thu, Mar 5, 2020 at 8:35 AM Neal Gompa wrote: > > > > On Thu, Mar 5, 2020 at 8:29 AM Daniel Mach wrote: > > > > > > > > > > > > Dne 04. 03. 20 v 23:01 Neal Gompa napsal(a): > > > > On Wed, Mar 4, 2020 at 4:37 PM Zbigniew Jędrzejewski-Szmek > > > > wrote: > > > >> Are you going to use sd-bus for the dbus library? > > > >> > > > > > > > > I'd hope not, given that we have cross-distro usage of DNF now, and a > > > > couple of them don't have systemd. > > > > > > > Do you know which distros do not have systemd? > > > > > > We have evaluated sd-bus to be the best dbus client available, but we > > > may have underestimated it's adoption. > > > > > > Couldn't systemd team split it into a separate library independent on > > > the rest of the systemd eco-system? :) > > > > > > > Off the top of my head: PLD and ALT do not mandate systemd usage, and > > their default setup is still sysvinit. > > > > PCLinuxOS also does not have systemd and does not currently intend on > > including it. > > If I were weighing the value of having dnf work on those distributions > vs. building out a more robust and maintainable dnf for *most* > distributions, I would choose the later. My point here is that > cross-distro compatibility is important, but it is not the most > important thing. > Perhaps, but no code has been written yet, so this decision isn't set in stone. This is the perfect time to make sure we don't trap ourselves. And I also forgot all about Yocto, which switched to DNF back in Yocto 2.3. They do not use systemd by default in a lot of cases, and having DNF work there without systemd is valuable because of all the configurations they offer that systemd does not support. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Announcing start of DNF 5 development
On Thu, Mar 5, 2020 at 9:00 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Thu, Mar 05, 2020 at 02:29:38PM +0100, Daniel Mach wrote: > > > > > > Dne 04. 03. 20 v 23:01 Neal Gompa napsal(a): > > >On Wed, Mar 4, 2020 at 4:37 PM Zbigniew Jędrzejewski-Szmek > > > wrote: > > >>Are you going to use sd-bus for the dbus library? > > >> > > > > > >I'd hope not, given that we have cross-distro usage of DNF now, and a > > >couple of them don't have systemd. > > > > > Do you know which distros do not have systemd? > > > > We have evaluated sd-bus to be the best dbus client available, but > > we may have underestimated it's adoption. > > > > Couldn't systemd team split it into a separate library independent > > on the rest of the systemd eco-system? :) > > It's already a separate library independent from the rest of the > systemd eco-system ;) > > (OK, it's a single library with other parts included, but the sd-bus > part is the biggest by far, and also sd-bus uses sd-event and sd-128 > internally, so they'd be required anyway. The other parts are smaller, > and matter more because of dependencies they pull in than because of > the code size itself. But it is possible to compile libsystemd w/o > some features, notably without encryption, to save size and deps. > I don't think there's any significant barrier to using libsystemd > on non-systemd systems, except for psychological issues.) > Don't discount psychological issues. The original reason for DNF not being named YUM was so that the project would be free to do better without the YUM baggage. That had the added effect of making it easier to propose for other distributions to adopt because YUM has a very negative reputation outside of the RHEL space. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Announcing start of DNF 5 development
On Thu, Mar 5, 2020 at 8:35 AM Neal Gompa wrote: > > On Thu, Mar 5, 2020 at 8:29 AM Daniel Mach wrote: > > > > > > > > Dne 04. 03. 20 v 23:01 Neal Gompa napsal(a): > > > On Wed, Mar 4, 2020 at 4:37 PM Zbigniew Jędrzejewski-Szmek > > > wrote: > > >> Are you going to use sd-bus for the dbus library? > > >> > > > > > > I'd hope not, given that we have cross-distro usage of DNF now, and a > > > couple of them don't have systemd. > > > > > Do you know which distros do not have systemd? > > > > We have evaluated sd-bus to be the best dbus client available, but we > > may have underestimated it's adoption. > > > > Couldn't systemd team split it into a separate library independent on > > the rest of the systemd eco-system? :) > > > > Off the top of my head: PLD and ALT do not mandate systemd usage, and > their default setup is still sysvinit. > > PCLinuxOS also does not have systemd and does not currently intend on > including it. If I were weighing the value of having dnf work on those distributions vs. building out a more robust and maintainable dnf for *most* distributions, I would choose the later. My point here is that cross-distro compatibility is important, but it is not the most important thing. josh > Also, I can't use systemd stuff on darwin-based systems (macOS and > PureDarwin), even though that may not matter to you. :) > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Announcing start of DNF 5 development
On Thu, Mar 05, 2020 at 02:29:38PM +0100, Daniel Mach wrote: > > > Dne 04. 03. 20 v 23:01 Neal Gompa napsal(a): > >On Wed, Mar 4, 2020 at 4:37 PM Zbigniew Jędrzejewski-Szmek > > wrote: > >>Are you going to use sd-bus for the dbus library? > >> > > > >I'd hope not, given that we have cross-distro usage of DNF now, and a > >couple of them don't have systemd. > > > Do you know which distros do not have systemd? > > We have evaluated sd-bus to be the best dbus client available, but > we may have underestimated it's adoption. > > Couldn't systemd team split it into a separate library independent > on the rest of the systemd eco-system? :) It's already a separate library independent from the rest of the systemd eco-system ;) (OK, it's a single library with other parts included, but the sd-bus part is the biggest by far, and also sd-bus uses sd-event and sd-128 internally, so they'd be required anyway. The other parts are smaller, and matter more because of dependencies they pull in than because of the code size itself. But it is possible to compile libsystemd w/o some features, notably without encryption, to save size and deps. I don't think there's any significant barrier to using libsystemd on non-systemd systems, except for psychological issues.) Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Announcing start of DNF 5 development
On Thu, Mar 5, 2020 at 8:29 AM Daniel Mach wrote: > > > > Dne 04. 03. 20 v 23:01 Neal Gompa napsal(a): > > On Wed, Mar 4, 2020 at 4:37 PM Zbigniew Jędrzejewski-Szmek > > wrote: > >> Are you going to use sd-bus for the dbus library? > >> > > > > I'd hope not, given that we have cross-distro usage of DNF now, and a > > couple of them don't have systemd. > > > Do you know which distros do not have systemd? > > We have evaluated sd-bus to be the best dbus client available, but we > may have underestimated it's adoption. > > Couldn't systemd team split it into a separate library independent on > the rest of the systemd eco-system? :) > Off the top of my head: PLD and ALT do not mandate systemd usage, and their default setup is still sysvinit. PCLinuxOS also does not have systemd and does not currently intend on including it. Also, I can't use systemd stuff on darwin-based systems (macOS and PureDarwin), even though that may not matter to you. :) -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Announcing start of DNF 5 development
Dne 04. 03. 20 v 23:01 Neal Gompa napsal(a): On Wed, Mar 4, 2020 at 4:37 PM Zbigniew Jędrzejewski-Szmek wrote: Are you going to use sd-bus for the dbus library? I'd hope not, given that we have cross-distro usage of DNF now, and a couple of them don't have systemd. Do you know which distros do not have systemd? We have evaluated sd-bus to be the best dbus client available, but we may have underestimated it's adoption. Couldn't systemd team split it into a separate library independent on the rest of the systemd eco-system? :) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Announcing start of DNF 5 development
On Thu, Mar 5, 2020 at 7:06 AM Marcin Juszkiewicz wrote: > > W dniu 04.03.2020 o 19:03, Daniel Mach pisze: > > Hello everyone, I'm pleased to announce start of DNF 5 development. > > > microdnf > > Microdnf is becoming important because it's part of > > many containers due to its small footprint. > > [root@puchatek hrw]# ldd /bin/microdnf |wc -l > 70 > > hrw@j13-qrep-04:ceph-12.2.11$ ldd /usr/bin/apt|wc -l > 20 > Apt's library dependencies are a lie if you look just at /usr/bin/apt, as it relies very heavily on subprocessing for core functionality. You'd need to check and add the dependencies of the helper binaries that are required for apt functionality. Last I checked with 1.9.10, it's fairly comparable. > Are there plans for picodnf then? Or cutting amount of > libraries used by microdnf? > > My problem with DNF is Python. There is a huge amount of > packages which need to be in proper state to be able to use > dnf. I remember when I did some experiments with RHEL7 and > managed to get to the point where 'yum' was unable to help > as Python was broken. Micro DNF is in C (using glib/gobject) today and would be in C++ in the future. The transition from C to C++ will allow the GNOME library ecosystem to be fully dropped as a dependency from the DNF stack. That is substantial baggage that will finally go away. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Announcing start of DNF 5 development
W dniu 04.03.2020 o 19:03, Daniel Mach pisze: > Hello everyone, I'm pleased to announce start of DNF 5 development. > microdnf > Microdnf is becoming important because it's part of > many containers due to its small footprint. [root@puchatek hrw]# ldd /bin/microdnf |wc -l 70 hrw@j13-qrep-04:ceph-12.2.11$ ldd /usr/bin/apt|wc -l 20 Are there plans for picodnf then? Or cutting amount of libraries used by microdnf? My problem with DNF is Python. There is a huge amount of packages which need to be in proper state to be able to use dnf. I remember when I did some experiments with RHEL7 and managed to get to the point where 'yum' was unable to help as Python was broken. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Announcing start of DNF 5 development
On Thu, Mar 5, 2020 at 5:58 AM Martin Kolman wrote: > > On Thu, 2020-03-05 at 08:56 +0100, jkone...@redhat.com wrote: > > On Thu, 2020-03-05 at 07:44 +0100, Fabio Valentini wrote: > > On Thu, Mar 5, 2020, 00:55 Martin Kolman wrote: > > > > - Original Message - > > From: "Neal Gompa" > > To: "Development discussions related to Fedora" > > > > Sent: Wednesday, March 4, 2020 11:01:43 PM > > Subject: Re: Announcing start of DNF 5 development > > > > On Wed, Mar 4, 2020 at 4:37 PM Zbigniew Jędrzejewski-Szmek > > wrote: > > > > > > On Wed, Mar 04, 2020 at 07:03:01PM +0100, Daniel Mach wrote: > > > > Hello everyone, > > > > I'm pleased to announce start of DNF 5 development. We are planning > > > > to deliver a module stream or a COPR repo during Fedora 33 > > > > development for early adopters and tool developers and we're hoping > > > > in getting a stable version into Fedora 34. > > > > > > > > > > > > More details follow. > > > > > > > > > > > > We've managed to drop a lot of redundant code across the whole DNF > > > > stack in the past years, but we have reached a point when it's > > > > nearly impossible to consolidate the code any further without > > > > breaking the API/ABI. Especially with PackageKit being dead[1], we > > > > can't move with the old "libhif" API in libdnf, because making any > > > > bigger changes to PackageKit is clearly out of scope. > > > > > > > > [1] > > > > https://blogs.gnome.org/hughsie/2019/02/14/packagekit-is-dead-long-live-well-something-else/ > > > > > > > > > > > > That's why we decided to start working on a new version of the DNF > > > > stack: DNF 5. And this is the plan: > > > > > > > > > > > > Priorities > > > > -- > > > > 1. Consistency, documentation and user experience is the top priority. > > > > 2. Compatibility on the command line level. > > > > 3. Compatibility on the API level. > > > > > > > > > > > > Maintenance > > > > --- > > > > The existing DNF 4 stack stays in the current Fedoras and Red Hat > > > > Enterprise Linux 8. We'll keep maintaining it in dnf-4-master > > > > branches on GitHub. PackageKit and rpm-ostree will stay on libdnf > > > > from the DNF 4 stack. > > > > > > > > > > > > The existing Python API in DNF > > > > -- > > > > The Python API in DNF stays. We'll do our best to keep it working. > > > > If there is an incompatible change, we'll communicate and document > > > > it properly. > > > > > > > > > > > > The new API in libdnf > > > > - > > > > All business logic will move from DNF (Python) to libdnf (C++). This > > > > is the only way to ensure that package managers work identically > > > > across the whole distribution. We'll start with C++ API and > > > > auto-generated Python bindings via SWIG. We'll focus on the Python > > > > bindings which are required by DNF and we will do our best to > > > > provide bindings for Go, Perl5 and Ruby as well. C API will be > > > > created later when the C++ API is stable. At that moment rpm-ostree > > > > will be ported to the new C API. > > > > > > > > > > > > hawkey > > > > -- > > > > Hawkey Python API is going away and will be replaced with libdnf Python > > > > API. > > > > > > > > > > > > DNF > > > > --- > > > > DNF stays as the primary command-line package manager. The overall > > > > functionality remains. We don't anticipate any negative impact of > > > > the API rewrite on the end-users. We have built an extensive test > > > > suite (over 1400 scenarios) that will help us to ensure that. The > > > > argument parser and outputs may slightly change in some cases to > > > > provide a more consistent user-experience. All such cases will be > > > > properly documented. > > > > > > > > > > > > microdnf > > > > > > > > Microdnf is becoming important because it's part of many containers >
Re: Announcing start of DNF 5 development
On Thu, 2020-03-05 at 08:56 +0100, jkone...@redhat.com wrote: > On Thu, 2020-03-05 at 07:44 +0100, Fabio Valentini wrote: > > On Thu, Mar 5, 2020, 00:55 Martin Kolman wrote: > > > > > > > > > - Original Message - > > > > > > > From: "Neal Gompa" > > > > > > > To: "Development discussions related to Fedora" > > > > > > > > > > > Sent: Wednesday, March 4, 2020 11:01:43 PM > > > > > > > Subject: Re: Announcing start of DNF 5 development > > > > > > > > > > > > > > On Wed, Mar 4, 2020 at 4:37 PM Zbigniew Jędrzejewski-Szmek > > > > > > > wrote: > > > > > > > > > > > > > > > > On Wed, Mar 04, 2020 at 07:03:01PM +0100, Daniel Mach wrote: > > > > > > > > > Hello everyone, > > > > > > > > > I'm pleased to announce start of DNF 5 development. We are planning > > > > > > > > > to deliver a module stream or a COPR repo during Fedora 33 > > > > > > > > > development for early adopters and tool developers and we're hoping > > > > > > > > > in getting a stable version into Fedora 34. > > > > > > > > > > > > > > > > > > > > > > > > > > > More details follow. > > > > > > > > > > > > > > > > > > > > > > > > > > > We've managed to drop a lot of redundant code across the whole DNF > > > > > > > > > stack in the past years, but we have reached a point when it's > > > > > > > > > nearly impossible to consolidate the code any further without > > > > > > > > > breaking the API/ABI. Especially with PackageKit being dead[1], we > > > > > > > > > can't move with the old "libhif" API in libdnf, because making any > > > > > > > > > bigger changes to PackageKit is clearly out of scope. > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > https://blogs.gnome.org/hughsie/2019/02/14/packagekit-is-dead-long-live-well-something-else/ > > > > > > > > > > > > > > > > > > > > > > > > > > > That's why we decided to start working on a new version of the DNF > > > > > > > > > stack: DNF 5. And this is the plan: > > > > > > > > > > > > > > > > > > > > > > > > > > > Priorities > > > > > > > > > -- > > > > > > > > > 1. Consistency, documentation and user experience is the top > > > > > > priority. > > > > > > > > > 2. Compatibility on the command line level. > > > > > > > > > 3. Compatibility on the API level. > > > > > > > > > > > > > > > > > > > > > > > > > > > Maintenance > > > > > > > > > --- > > > > > > > > > The existing DNF 4 stack stays in the current Fedoras and Red Hat > > > > > > > > > Enterprise Linux 8. We'll keep maintaining it in dnf-4-master > > > > > > > > > branches on GitHub. PackageKit and rpm-ostree will stay on libdnf > > > > > > > > > from the DNF 4 stack. > > > > > > > > > > > > > > > > > > > > > > > > > > > The existing Python API in DNF > > > > > > > > > -- > > > > > > > > > The Python API in DNF stays. We'll do our best to keep it working. > > > > > > > > > If there is an incompatible change, we'll communicate and document > > > > > > > > > it properly. > > > > > > > > > > > > > > > > > > > > > > > > > > > The new API in libdnf > > > > > > > > > - > > > > > > > > > All business logic will move from DNF (Python) to libdnf (C++). This > > > > > > > > > is the only way to ensure that package managers w
Re: Announcing start of DNF 5 development
On Thu, 2020-03-05 at 09:11 +0100, Fabio Valentini wrote: > On Thu, Mar 5, 2020, 08:56 wrote: > > On Thu, 2020-03-05 at 07:44 +0100, Fabio Valentini wrote: > > > On Thu, Mar 5, 2020, 00:55 Martin Kolman wrote: > > > > > > > > > > > > - Original Message - > > > > > > > > > From: "Neal Gompa" > > > > > > > > > To: "Development discussions related to Fedora" > > > > > > > > > > > > > > Sent: Wednesday, March 4, 2020 11:01:43 PM > > > > > > > > > Subject: Re: Announcing start of DNF 5 development > > > > > > > > > > > > > > > > > > On Wed, Mar 4, 2020 at 4:37 PM Zbigniew Jędrzejewski-Szmek > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > On Wed, Mar 04, 2020 at 07:03:01PM +0100, Daniel Mach wrote: > > > > > > > > > > > Hello everyone, > > > > > > > > > > > I'm pleased to announce start of DNF 5 development. We are > > > > > > > planning > > > > > > > > > > > to deliver a module stream or a COPR repo during Fedora 33 > > > > > > > > > > > development for early adopters and tool developers and we're > > > > > > > hoping > > > > > > > > > > > in getting a stable version into Fedora 34. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > More details follow. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We've managed to drop a lot of redundant code across the whole DNF > > > > > > > > > > > stack in the past years, but we have reached a point when it's > > > > > > > > > > > nearly impossible to consolidate the code any further without > > > > > > > > > > > breaking the API/ABI. Especially with PackageKit being dead[1], we > > > > > > > > > > > can't move with the old "libhif" API in libdnf, because making any > > > > > > > > > > > bigger changes to PackageKit is clearly out of scope. > > > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > https://blogs.gnome.org/hughsie/2019/02/14/packagekit-is-dead-long-live-well-something-else/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > That's why we decided to start working on a new version of the DNF > > > > > > > > > > > stack: DNF 5. And this is the plan: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Priorities > > > > > > > > > > > -- > > > > > > > > > > > 1. Consistency, documentation and user experience is the top > > > > > > > priority. > > > > > > > > > > > 2. Compatibility on the command line level. > > > > > > > > > > > 3. Compatibility on the API level. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Maintenance > > > > > > > > > > > --- > > > > > > > > > > > The existing DNF 4 stack stays in the current Fedoras and Red Hat > > > > > > > > > > > Enterprise Linux 8. We'll keep maintaining it in dnf-4-master > > > > > > > > > > > branches on GitHub. PackageKit and rpm-ostree will stay on libdnf > > > > > > > > > > > from the DNF 4 stack. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The existing Python API in DNF > > > > > > > > > > > -- > > > > > > > > > > > The Python API in DNF s
Re: Announcing start of DNF 5 development
Kamil Paral wrote: > On Wed, Mar 4, 2020 at 7:04 PM Daniel Mach wrote: > >> Hello everyone, >> I'm pleased to announce start of DNF 5 development. We are planning to >> deliver a module stream or a COPR repo during Fedora 33 development for >> early adopters and tool developers and we're hoping in getting a stable >> version into Fedora 34. >> >> > Thanks for the announcement. I definitely prefer a COPR repo to a module > stream :-) +1 Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Announcing start of DNF 5 development
On Thu, Mar 5, 2020, 08:56 wrote: > On Thu, 2020-03-05 at 07:44 +0100, Fabio Valentini wrote: > > On Thu, Mar 5, 2020, 00:55 Martin Kolman wrote: > > > > - Original Message - > > From: "Neal Gompa" > > To: "Development discussions related to Fedora" < > devel@lists.fedoraproject.org> > > Sent: Wednesday, March 4, 2020 11:01:43 PM > > Subject: Re: Announcing start of DNF 5 development > > > > On Wed, Mar 4, 2020 at 4:37 PM Zbigniew Jędrzejewski-Szmek > > wrote: > > > > > > On Wed, Mar 04, 2020 at 07:03:01PM +0100, Daniel Mach wrote: > > > > Hello everyone, > > > > I'm pleased to announce start of DNF 5 development. We are planning > > > > to deliver a module stream or a COPR repo during Fedora 33 > > > > development for early adopters and tool developers and we're hoping > > > > in getting a stable version into Fedora 34. > > > > > > > > > > > > More details follow. > > > > > > > > > > > > We've managed to drop a lot of redundant code across the whole DNF > > > > stack in the past years, but we have reached a point when it's > > > > nearly impossible to consolidate the code any further without > > > > breaking the API/ABI. Especially with PackageKit being dead[1], we > > > > can't move with the old "libhif" API in libdnf, because making any > > > > bigger changes to PackageKit is clearly out of scope. > > > > > > > > [1] > > > > > https://blogs.gnome.org/hughsie/2019/02/14/packagekit-is-dead-long-live-well-something-else/ > > > > > > > > > > > > That's why we decided to start working on a new version of the DNF > > > > stack: DNF 5. And this is the plan: > > > > > > > > > > > > Priorities > > > > -- > > > > 1. Consistency, documentation and user experience is the top > priority. > > > > 2. Compatibility on the command line level. > > > > 3. Compatibility on the API level. > > > > > > > > > > > > Maintenance > > > > --- > > > > The existing DNF 4 stack stays in the current Fedoras and Red Hat > > > > Enterprise Linux 8. We'll keep maintaining it in dnf-4-master > > > > branches on GitHub. PackageKit and rpm-ostree will stay on libdnf > > > > from the DNF 4 stack. > > > > > > > > > > > > The existing Python API in DNF > > > > -- > > > > The Python API in DNF stays. We'll do our best to keep it working. > > > > If there is an incompatible change, we'll communicate and document > > > > it properly. > > > > > > > > > > > > The new API in libdnf > > > > - > > > > All business logic will move from DNF (Python) to libdnf (C++). This > > > > is the only way to ensure that package managers work identically > > > > across the whole distribution. We'll start with C++ API and > > > > auto-generated Python bindings via SWIG. We'll focus on the Python > > > > bindings which are required by DNF and we will do our best to > > > > provide bindings for Go, Perl5 and Ruby as well. C API will be > > > > created later when the C++ API is stable. At that moment rpm-ostree > > > > will be ported to the new C API. > > > > > > > > > > > > hawkey > > > > -- > > > > Hawkey Python API is going away and will be replaced with libdnf > Python > > > > API. > > > > > > > > > > > > DNF > > > > --- > > > > DNF stays as the primary command-line package manager. The overall > > > > functionality remains. We don't anticipate any negative impact of > > > > the API rewrite on the end-users. We have built an extensive test > > > > suite (over 1400 scenarios) that will help us to ensure that. The > > > > argument parser and outputs may slightly change in some cases to > > > > provide a more consistent user-experience. All such cases will be > > > > properly documented. > > > > > > > > > > > > microdnf > > > > > > > > Microdnf is becoming important because it's part of many containers > > > > due to its small footprint. We
Re: Announcing start of DNF 5 development
On Thu, 2020-03-05 at 07:44 +0100, Fabio Valentini wrote: > On Thu, Mar 5, 2020, 00:55 Martin Kolman wrote: > > > > > > - Original Message - > > > > > From: "Neal Gompa" > > > > > To: "Development discussions related to Fedora" < > > devel@lists.fedoraproject.org> > > > > > Sent: Wednesday, March 4, 2020 11:01:43 PM > > > > > Subject: Re: Announcing start of DNF 5 development > > > > > > > > > > On Wed, Mar 4, 2020 at 4:37 PM Zbigniew Jędrzejewski-Szmek > > > > > wrote: > > > > > > > > > > > > On Wed, Mar 04, 2020 at 07:03:01PM +0100, Daniel Mach wrote: > > > > > > > Hello everyone, > > > > > > > I'm pleased to announce start of DNF 5 development. We are > > planning > > > > > > > to deliver a module stream or a COPR repo during Fedora 33 > > > > > > > development for early adopters and tool developers and we're > > hoping > > > > > > > in getting a stable version into Fedora 34. > > > > > > > > > > > > > > > > > > > > > More details follow. > > > > > > > > > > > > > > > > > > > > > We've managed to drop a lot of redundant code across the > > whole DNF > > > > > > > stack in the past years, but we have reached a point when > > it's > > > > > > > nearly impossible to consolidate the code any further without > > > > > > > breaking the API/ABI. Especially with PackageKit being > > dead[1], we > > > > > > > can't move with the old "libhif" API in libdnf, because > > making any > > > > > > > bigger changes to PackageKit is clearly out of scope. > > > > > > > > > > > > > > [1] > > > > > > > > > https://blogs.gnome.org/hughsie/2019/02/14/packagekit-is-dead-long-live-well-something-else/ > > > > > > > > > > > > > > > > > > > > > That's why we decided to start working on a new version of > > the DNF > > > > > > > stack: DNF 5. And this is the plan: > > > > > > > > > > > > > > > > > > > > > Priorities > > > > > > > -- > > > > > > > 1. Consistency, documentation and user experience is the top > > priority. > > > > > > > 2. Compatibility on the command line level. > > > > > > > 3. Compatibility on the API level. > > > > > > > > > > > > > > > > > > > > > Maintenance > > > > > > > --- > > > > > > > The existing DNF 4 stack stays in the current Fedoras and Red > > Hat > > > > > > > Enterprise Linux 8. We'll keep maintaining it in dnf-4-master > > > > > > > branches on GitHub. PackageKit and rpm-ostree will stay on > > libdnf > > > > > > > from the DNF 4 stack. > > > > > > > > > > > > > > > > > > > > > The existing Python API in DNF > > > > > > > -- > > > > > > > The Python API in DNF stays. We'll do our best to keep it > > working. > > > > > > > If there is an incompatible change, we'll communicate and > > document > > > > > > > it properly. > > > > > > > > > > > > > > > > > > > > > The new API in libdnf > > > > > > > - > > > > > > > All business logic will move from DNF (Python) to libdnf > > (C++). This > > > > > > > is the only way to ensure that package managers work > > identically > > > > > > > across the whole distribution. We'll start with C++ API and > > > > > > > auto-generated Python bindings via SWIG. We'll focus on the > > Python > > > > > > > bindings which are required by DNF and we will do our best to > > > > > > > provide bindings for Go, Perl5 and Ruby as well. C API will > > be > > > > > > > created later when the C++ API is stable. At that m
Re: Announcing start of DNF 5 development
On Wed, 2020-03-04 at 18:55 -0500, Martin Kolman wrote: > > - Original Message - > > From: "Neal Gompa" > > To: "Development discussions related to Fedora" < > > devel@lists.fedoraproject.org> > > Sent: Wednesday, March 4, 2020 11:01:43 PM > > Subject: Re: Announcing start of DNF 5 development > > > > On Wed, Mar 4, 2020 at 4:37 PM Zbigniew Jędrzejewski-Szmek > > wrote: > > > On Wed, Mar 04, 2020 at 07:03:01PM +0100, Daniel Mach wrote: > > > > Hello everyone, > > > > I'm pleased to announce start of DNF 5 development. We are > > > > planning > > > > to deliver a module stream or a COPR repo during Fedora 33 > > > > development for early adopters and tool developers and we're > > > > hoping > > > > in getting a stable version into Fedora 34. > > > > > > > > > > > > More details follow. > > > > > > > > > > > > We've managed to drop a lot of redundant code across the whole > > > > DNF > > > > stack in the past years, but we have reached a point when it's > > > > nearly impossible to consolidate the code any further without > > > > breaking the API/ABI. Especially with PackageKit being dead[1], > > > > we > > > > can't move with the old "libhif" API in libdnf, because making > > > > any > > > > bigger changes to PackageKit is clearly out of scope. > > > > > > > > [1] > > > > https://blogs.gnome.org/hughsie/2019/02/14/packagekit-is-dead-long-live-well-something-else/ > > > > > > > > > > > > That's why we decided to start working on a new version of the > > > > DNF > > > > stack: DNF 5. And this is the plan: > > > > > > > > > > > > Priorities > > > > -- > > > > 1. Consistency, documentation and user experience is the top > > > > priority. > > > > 2. Compatibility on the command line level. > > > > 3. Compatibility on the API level. > > > > > > > > > > > > Maintenance > > > > --- > > > > The existing DNF 4 stack stays in the current Fedoras and Red > > > > Hat > > > > Enterprise Linux 8. We'll keep maintaining it in dnf-4-master > > > > branches on GitHub. PackageKit and rpm-ostree will stay on > > > > libdnf > > > > from the DNF 4 stack. > > > > > > > > > > > > The existing Python API in DNF > > > > -- > > > > The Python API in DNF stays. We'll do our best to keep it > > > > working. > > > > If there is an incompatible change, we'll communicate and > > > > document > > > > it properly. > > > > > > > > > > > > The new API in libdnf > > > > - > > > > All business logic will move from DNF (Python) to libdnf (C++). > > > > This > > > > is the only way to ensure that package managers work > > > > identically > > > > across the whole distribution. We'll start with C++ API and > > > > auto-generated Python bindings via SWIG. We'll focus on the > > > > Python > > > > bindings which are required by DNF and we will do our best to > > > > provide bindings for Go, Perl5 and Ruby as well. C API will be > > > > created later when the C++ API is stable. At that moment rpm- > > > > ostree > > > > will be ported to the new C API. > > > > > > > > > > > > hawkey > > > > -- > > > > Hawkey Python API is going away and will be replaced with > > > > libdnf Python > > > > API. > > > > > > > > > > > > DNF > > > > --- > > > > DNF stays as the primary command-line package manager. The > > > > overall > > > > functionality remains. We don't anticipate any negative impact > > > > of > > > > the API rewrite on the end-users. We have built an extensive > > > > test > > > > suite (over 1400 scenarios) that will help us to ensure that. > > > > The > > > > argument parser and outputs may slightly change in some cases > > > > to > > > > provide a more consistent user-experien
Re: Announcing start of DNF 5 development
Dne 04. 03. 20 v 22:34 Zbigniew Jędrzejewski-Szmek napsal(a): On Wed, Mar 04, 2020 at 07:03:01PM +0100, Daniel Mach wrote: Hello everyone, I'm pleased to announce start of DNF 5 development. We are planning to deliver a module stream or a COPR repo during Fedora 33 development for early adopters and tool developers and we're hoping in getting a stable version into Fedora 34. More details follow. We've managed to drop a lot of redundant code across the whole DNF stack in the past years, but we have reached a point when it's nearly impossible to consolidate the code any further without breaking the API/ABI. Especially with PackageKit being dead[1], we can't move with the old "libhif" API in libdnf, because making any bigger changes to PackageKit is clearly out of scope. [1] https://blogs.gnome.org/hughsie/2019/02/14/packagekit-is-dead-long-live-well-something-else/ That's why we decided to start working on a new version of the DNF stack: DNF 5. And this is the plan: Priorities -- 1. Consistency, documentation and user experience is the top priority. 2. Compatibility on the command line level. 3. Compatibility on the API level. Maintenance --- The existing DNF 4 stack stays in the current Fedoras and Red Hat Enterprise Linux 8. We'll keep maintaining it in dnf-4-master branches on GitHub. PackageKit and rpm-ostree will stay on libdnf from the DNF 4 stack. The existing Python API in DNF -- The Python API in DNF stays. We'll do our best to keep it working. If there is an incompatible change, we'll communicate and document it properly. The new API in libdnf - All business logic will move from DNF (Python) to libdnf (C++). This is the only way to ensure that package managers work identically across the whole distribution. We'll start with C++ API and auto-generated Python bindings via SWIG. We'll focus on the Python bindings which are required by DNF and we will do our best to provide bindings for Go, Perl5 and Ruby as well. C API will be created later when the C++ API is stable. At that moment rpm-ostree will be ported to the new C API. hawkey -- Hawkey Python API is going away and will be replaced with libdnf Python API. DNF --- DNF stays as the primary command-line package manager. The overall functionality remains. We don't anticipate any negative impact of the API rewrite on the end-users. We have built an extensive test suite (over 1400 scenarios) that will help us to ensure that. The argument parser and outputs may slightly change in some cases to provide a more consistent user-experience. All such cases will be properly documented. microdnf Microdnf is becoming important because it's part of many containers due to its small footprint. We're getting feedback that users would appreciate something closer to DNF. We'll focus on implementing a subset of DNF's functionality and improving the user experience. 100% feature parity with DNF is currently out of scope. Hi, the roadmap is ambitious, but not impossible. Good luck! Thanks! Roadmap (tentative) --- * Mar 2020 - making the bigger API changes, upstream code barely compiles * May 2020 - COPR repo with first development snapshots * Jun 2020 - F33 module available for early adopters and tool developers * Oct 2020 - DNF 5 landing in F34 Rawhide * Feb 2021 - DNF 5 replacing DNF 4 in stable Fedora DBus service DNF team has decided to create a new DBus service replacing PackageKit to provide an interface to GUI applications. It's probably going to take a while because we're planning to start from scratch. Do you plan to make normal 'dnf' calls go through the dbus api? (And e.g. provide a single cache and privilege escalation through packagekit)? No, dnf stays as it is, it's not going to switch to dbus. Single cache is part of the plan. Apart from the dbus api, do you plan to provide some graphical application that uses this api? Definitely not at this moment. We need to build the new service and integrate it with the existing tools first. We may create a simple command-line tool replacing pkcon, something like microdnf over dbus. Are you going to use sd-bus for the dbus library? Yes, it's going to be sd-bus + sdbus-cpp: * https://github.com/Kistler-Group/sdbus-cpp * https://src.fedoraproject.org/rpms/sdbus-cpp ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Announcing start of DNF 5 development
On Thu, Mar 5, 2020, 00:55 Martin Kolman wrote: > > > - Original Message - > > From: "Neal Gompa" > > To: "Development discussions related to Fedora" < > devel@lists.fedoraproject.org> > > Sent: Wednesday, March 4, 2020 11:01:43 PM > > Subject: Re: Announcing start of DNF 5 development > > > > On Wed, Mar 4, 2020 at 4:37 PM Zbigniew Jędrzejewski-Szmek > > wrote: > > > > > > On Wed, Mar 04, 2020 at 07:03:01PM +0100, Daniel Mach wrote: > > > > Hello everyone, > > > > I'm pleased to announce start of DNF 5 development. We are planning > > > > to deliver a module stream or a COPR repo during Fedora 33 > > > > development for early adopters and tool developers and we're hoping > > > > in getting a stable version into Fedora 34. > > > > > > > > > > > > More details follow. > > > > > > > > > > > > We've managed to drop a lot of redundant code across the whole DNF > > > > stack in the past years, but we have reached a point when it's > > > > nearly impossible to consolidate the code any further without > > > > breaking the API/ABI. Especially with PackageKit being dead[1], we > > > > can't move with the old "libhif" API in libdnf, because making any > > > > bigger changes to PackageKit is clearly out of scope. > > > > > > > > [1] > > > > > https://blogs.gnome.org/hughsie/2019/02/14/packagekit-is-dead-long-live-well-something-else/ > > > > > > > > > > > > That's why we decided to start working on a new version of the DNF > > > > stack: DNF 5. And this is the plan: > > > > > > > > > > > > Priorities > > > > -- > > > > 1. Consistency, documentation and user experience is the top > priority. > > > > 2. Compatibility on the command line level. > > > > 3. Compatibility on the API level. > > > > > > > > > > > > Maintenance > > > > --- > > > > The existing DNF 4 stack stays in the current Fedoras and Red Hat > > > > Enterprise Linux 8. We'll keep maintaining it in dnf-4-master > > > > branches on GitHub. PackageKit and rpm-ostree will stay on libdnf > > > > from the DNF 4 stack. > > > > > > > > > > > > The existing Python API in DNF > > > > -- > > > > The Python API in DNF stays. We'll do our best to keep it working. > > > > If there is an incompatible change, we'll communicate and document > > > > it properly. > > > > > > > > > > > > The new API in libdnf > > > > - > > > > All business logic will move from DNF (Python) to libdnf (C++). This > > > > is the only way to ensure that package managers work identically > > > > across the whole distribution. We'll start with C++ API and > > > > auto-generated Python bindings via SWIG. We'll focus on the Python > > > > bindings which are required by DNF and we will do our best to > > > > provide bindings for Go, Perl5 and Ruby as well. C API will be > > > > created later when the C++ API is stable. At that moment rpm-ostree > > > > will be ported to the new C API. > > > > > > > > > > > > hawkey > > > > -- > > > > Hawkey Python API is going away and will be replaced with libdnf > Python > > > > API. > > > > > > > > > > > > DNF > > > > --- > > > > DNF stays as the primary command-line package manager. The overall > > > > functionality remains. We don't anticipate any negative impact of > > > > the API rewrite on the end-users. We have built an extensive test > > > > suite (over 1400 scenarios) that will help us to ensure that. The > > > > argument parser and outputs may slightly change in some cases to > > > > provide a more consistent user-experience. All such cases will be > > > > properly documented. > > > > > > > > > > > > microdnf > > > > > > > > Microdnf is becoming important because it's part of many containers > > > > due to its small footprint. We're getting feedback that users would > > > > appreciate something closer to DNF. We'll focu
Re: Announcing start of DNF 5 development
- Original Message - > From: "Neal Gompa" > To: "Development discussions related to Fedora" > > Sent: Wednesday, March 4, 2020 11:01:43 PM > Subject: Re: Announcing start of DNF 5 development > > On Wed, Mar 4, 2020 at 4:37 PM Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Wed, Mar 04, 2020 at 07:03:01PM +0100, Daniel Mach wrote: > > > Hello everyone, > > > I'm pleased to announce start of DNF 5 development. We are planning > > > to deliver a module stream or a COPR repo during Fedora 33 > > > development for early adopters and tool developers and we're hoping > > > in getting a stable version into Fedora 34. > > > > > > > > > More details follow. > > > > > > > > > We've managed to drop a lot of redundant code across the whole DNF > > > stack in the past years, but we have reached a point when it's > > > nearly impossible to consolidate the code any further without > > > breaking the API/ABI. Especially with PackageKit being dead[1], we > > > can't move with the old "libhif" API in libdnf, because making any > > > bigger changes to PackageKit is clearly out of scope. > > > > > > [1] > > > https://blogs.gnome.org/hughsie/2019/02/14/packagekit-is-dead-long-live-well-something-else/ > > > > > > > > > That's why we decided to start working on a new version of the DNF > > > stack: DNF 5. And this is the plan: > > > > > > > > > Priorities > > > -- > > > 1. Consistency, documentation and user experience is the top priority. > > > 2. Compatibility on the command line level. > > > 3. Compatibility on the API level. > > > > > > > > > Maintenance > > > --- > > > The existing DNF 4 stack stays in the current Fedoras and Red Hat > > > Enterprise Linux 8. We'll keep maintaining it in dnf-4-master > > > branches on GitHub. PackageKit and rpm-ostree will stay on libdnf > > > from the DNF 4 stack. > > > > > > > > > The existing Python API in DNF > > > -- > > > The Python API in DNF stays. We'll do our best to keep it working. > > > If there is an incompatible change, we'll communicate and document > > > it properly. > > > > > > > > > The new API in libdnf > > > - > > > All business logic will move from DNF (Python) to libdnf (C++). This > > > is the only way to ensure that package managers work identically > > > across the whole distribution. We'll start with C++ API and > > > auto-generated Python bindings via SWIG. We'll focus on the Python > > > bindings which are required by DNF and we will do our best to > > > provide bindings for Go, Perl5 and Ruby as well. C API will be > > > created later when the C++ API is stable. At that moment rpm-ostree > > > will be ported to the new C API. > > > > > > > > > hawkey > > > -- > > > Hawkey Python API is going away and will be replaced with libdnf Python > > > API. > > > > > > > > > DNF > > > --- > > > DNF stays as the primary command-line package manager. The overall > > > functionality remains. We don't anticipate any negative impact of > > > the API rewrite on the end-users. We have built an extensive test > > > suite (over 1400 scenarios) that will help us to ensure that. The > > > argument parser and outputs may slightly change in some cases to > > > provide a more consistent user-experience. All such cases will be > > > properly documented. > > > > > > > > > microdnf > > > > > > Microdnf is becoming important because it's part of many containers > > > due to its small footprint. We're getting feedback that users would > > > appreciate something closer to DNF. We'll focus on implementing a > > > subset of DNF's functionality and improving the user experience. > > > 100% feature parity with DNF is currently out of scope. > > > > > > > > Hi, > > > > the roadmap is ambitious, but not impossible. Good luck! > > > > > Roadmap (tentative) > > > --- > > > * Mar 2020 - making the bigger API changes, upstream code barely compiles > > > * May 2020 - COPR repo with first development snapshots > > > * Jun 2020 -
Re: Announcing start of DNF 5 development
On Wed, Mar 4, 2020 at 4:37 PM Zbigniew Jędrzejewski-Szmek wrote: > > On Wed, Mar 04, 2020 at 07:03:01PM +0100, Daniel Mach wrote: > > Hello everyone, > > I'm pleased to announce start of DNF 5 development. We are planning > > to deliver a module stream or a COPR repo during Fedora 33 > > development for early adopters and tool developers and we're hoping > > in getting a stable version into Fedora 34. > > > > > > More details follow. > > > > > > We've managed to drop a lot of redundant code across the whole DNF > > stack in the past years, but we have reached a point when it's > > nearly impossible to consolidate the code any further without > > breaking the API/ABI. Especially with PackageKit being dead[1], we > > can't move with the old "libhif" API in libdnf, because making any > > bigger changes to PackageKit is clearly out of scope. > > > > [1] > > https://blogs.gnome.org/hughsie/2019/02/14/packagekit-is-dead-long-live-well-something-else/ > > > > > > That's why we decided to start working on a new version of the DNF > > stack: DNF 5. And this is the plan: > > > > > > Priorities > > -- > > 1. Consistency, documentation and user experience is the top priority. > > 2. Compatibility on the command line level. > > 3. Compatibility on the API level. > > > > > > Maintenance > > --- > > The existing DNF 4 stack stays in the current Fedoras and Red Hat > > Enterprise Linux 8. We'll keep maintaining it in dnf-4-master > > branches on GitHub. PackageKit and rpm-ostree will stay on libdnf > > from the DNF 4 stack. > > > > > > The existing Python API in DNF > > -- > > The Python API in DNF stays. We'll do our best to keep it working. > > If there is an incompatible change, we'll communicate and document > > it properly. > > > > > > The new API in libdnf > > - > > All business logic will move from DNF (Python) to libdnf (C++). This > > is the only way to ensure that package managers work identically > > across the whole distribution. We'll start with C++ API and > > auto-generated Python bindings via SWIG. We'll focus on the Python > > bindings which are required by DNF and we will do our best to > > provide bindings for Go, Perl5 and Ruby as well. C API will be > > created later when the C++ API is stable. At that moment rpm-ostree > > will be ported to the new C API. > > > > > > hawkey > > -- > > Hawkey Python API is going away and will be replaced with libdnf Python API. > > > > > > DNF > > --- > > DNF stays as the primary command-line package manager. The overall > > functionality remains. We don't anticipate any negative impact of > > the API rewrite on the end-users. We have built an extensive test > > suite (over 1400 scenarios) that will help us to ensure that. The > > argument parser and outputs may slightly change in some cases to > > provide a more consistent user-experience. All such cases will be > > properly documented. > > > > > > microdnf > > > > Microdnf is becoming important because it's part of many containers > > due to its small footprint. We're getting feedback that users would > > appreciate something closer to DNF. We'll focus on implementing a > > subset of DNF's functionality and improving the user experience. > > 100% feature parity with DNF is currently out of scope. > > > > > Hi, > > the roadmap is ambitious, but not impossible. Good luck! > > > Roadmap (tentative) > > --- > > * Mar 2020 - making the bigger API changes, upstream code barely compiles > > * May 2020 - COPR repo with first development snapshots > > * Jun 2020 - F33 module available for early adopters and tool developers > > * Oct 2020 - DNF 5 landing in F34 Rawhide > > * Feb 2021 - DNF 5 replacing DNF 4 in stable Fedora > > > DBus service > > > > DNF team has decided to create a new DBus service replacing > > PackageKit to provide an interface to GUI applications. It's > > probably going to take a while because we're planning to start from > > scratch. > > Do you plan to make normal 'dnf' calls go through the dbus api? This would be interesting, but wouldn't that make using DNF in rescue situations impossible? > (And e.g. provide a single cache and privilege escalation through > packagekit)? > We can do the single cache thing *today* for PackageKit. The APIs exist in libdnf _now_, it's just that they're not used PackageKit-side. > Apart from the dbus api, do you plan to provide some graphical > application that uses this api? > I would expect that dnfdragora will be the first consumer of this new API, since this plan would essentially involve taking over the role of my dnfdaemon. > Are you going to use sd-bus for the dbus library? > I'd hope not, given that we have cross-distro usage of DNF now, and a couple of them don't have systemd. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an em
Re: Announcing start of DNF 5 development
On Wed, Mar 04, 2020 at 07:03:01PM +0100, Daniel Mach wrote: > Hello everyone, > I'm pleased to announce start of DNF 5 development. We are planning > to deliver a module stream or a COPR repo during Fedora 33 > development for early adopters and tool developers and we're hoping > in getting a stable version into Fedora 34. > > > More details follow. > > > We've managed to drop a lot of redundant code across the whole DNF > stack in the past years, but we have reached a point when it's > nearly impossible to consolidate the code any further without > breaking the API/ABI. Especially with PackageKit being dead[1], we > can't move with the old "libhif" API in libdnf, because making any > bigger changes to PackageKit is clearly out of scope. > > [1] > https://blogs.gnome.org/hughsie/2019/02/14/packagekit-is-dead-long-live-well-something-else/ > > > That's why we decided to start working on a new version of the DNF > stack: DNF 5. And this is the plan: > > > Priorities > -- > 1. Consistency, documentation and user experience is the top priority. > 2. Compatibility on the command line level. > 3. Compatibility on the API level. > > > Maintenance > --- > The existing DNF 4 stack stays in the current Fedoras and Red Hat > Enterprise Linux 8. We'll keep maintaining it in dnf-4-master > branches on GitHub. PackageKit and rpm-ostree will stay on libdnf > from the DNF 4 stack. > > > The existing Python API in DNF > -- > The Python API in DNF stays. We'll do our best to keep it working. > If there is an incompatible change, we'll communicate and document > it properly. > > > The new API in libdnf > - > All business logic will move from DNF (Python) to libdnf (C++). This > is the only way to ensure that package managers work identically > across the whole distribution. We'll start with C++ API and > auto-generated Python bindings via SWIG. We'll focus on the Python > bindings which are required by DNF and we will do our best to > provide bindings for Go, Perl5 and Ruby as well. C API will be > created later when the C++ API is stable. At that moment rpm-ostree > will be ported to the new C API. > > > hawkey > -- > Hawkey Python API is going away and will be replaced with libdnf Python API. > > > DNF > --- > DNF stays as the primary command-line package manager. The overall > functionality remains. We don't anticipate any negative impact of > the API rewrite on the end-users. We have built an extensive test > suite (over 1400 scenarios) that will help us to ensure that. The > argument parser and outputs may slightly change in some cases to > provide a more consistent user-experience. All such cases will be > properly documented. > > > microdnf > > Microdnf is becoming important because it's part of many containers > due to its small footprint. We're getting feedback that users would > appreciate something closer to DNF. We'll focus on implementing a > subset of DNF's functionality and improving the user experience. > 100% feature parity with DNF is currently out of scope. > > Hi, the roadmap is ambitious, but not impossible. Good luck! > Roadmap (tentative) > --- > * Mar 2020 - making the bigger API changes, upstream code barely compiles > * May 2020 - COPR repo with first development snapshots > * Jun 2020 - F33 module available for early adopters and tool developers > * Oct 2020 - DNF 5 landing in F34 Rawhide > * Feb 2021 - DNF 5 replacing DNF 4 in stable Fedora > DBus service > > DNF team has decided to create a new DBus service replacing > PackageKit to provide an interface to GUI applications. It's > probably going to take a while because we're planning to start from > scratch. Do you plan to make normal 'dnf' calls go through the dbus api? (And e.g. provide a single cache and privilege escalation through packagekit)? Apart from the dbus api, do you plan to provide some graphical application that uses this api? Are you going to use sd-bus for the dbus library? Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Announcing start of DNF 5 development
On Wed, Mar 4, 2020 at 7:04 PM Daniel Mach wrote: > Hello everyone, > I'm pleased to announce start of DNF 5 development. We are planning to > deliver a module stream or a COPR repo during Fedora 33 development for > early adopters and tool developers and we're hoping in getting a stable > version into Fedora 34. > > Thanks for the announcement. I definitely prefer a COPR repo to a module stream :-) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
