Following is the list of topics that will be discussed in the FESCo meeting Tuesday at 17:00UTC in #fedora-meeting on irc.libera.chat.
To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto
or run: date -d '2023-01-31 17:00 UTC'
Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda
= Discussed and Voted in the Ticket =
#2942 Change: IPP-USB as a weak dependency of CUPS and sane-airscan https://pagure.io/fesco/issue/2942 APPROVED (+3,0,-0)
#2941 Go 1.19 in Fedora 36 https://pagure.io/fesco/issue/2941 APPROVED (+4, 0, 0)
#2939 Change: Unfiltered Flathub https://pagure.io/fesco/issue/2939 APPROVED (+3,1,-0)
#2938 Change: Noto CJK Variable Fonts https://pagure.io/fesco/issue/2938 APPROVED (+3,0,-0)
= Followups =
= New business =
#2934 Restore Provides: singularity to apptainer packaging https://pagure.io/fesco/issue/2934
= Open Floor =
For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda
If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting.
= Meeting =
I forgot to send out the summary yesterday. The meeting was cancelled because of lack of quorum.
Minutes: https://meetbot.fedoraproject.org/fedora-meeting/2023-01-31/fesco.2023-01-31... Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting/2023-01-31/fesco.2023-01-31... Log: https://meetbot.fedoraproject.org/fedora-meeting/2023-01-31/fesco.2023-01-31...
= Discussed and Voted in the Ticket =
Two additional tickets were approved yesterday after I send out the agenda. I'm announcing them here so they don't need to wait another week.
#2943 Replace iscsi.service by iscsci-starter.service in presets https://pagure.io/issue/2943 APPROVED (+8, 0, 0)
#2870 Change proposal: Replace DNF with DNF5 https://pagure.io/issue/2870 APPROVED (+6,0,-0)
On 2023-02-01 13:38, Zbigniew Jędrzejewski-Szmek wrote:
#2870 Change proposal: Replace DNF with DNF5 https://pagure.io/fesco/issue/2870 APPROVED (+6,0,-0)
(Fixed the link above)
The change proposal calls for dnf5 to be ready by the time that F39 is branched, on Aug 8 of this year.
Right now, I don't see any documentation for plugins, the general API docs are (subjectively) terse, and the DNF5 git repo has a banner with warning signs that says "The API/ABI is currently unstable." (...which seems very odd, since 5.0.1 was released in November, so one would expect that the API has been stable since at least that time.)
The change proposal doesn't seem to consider gnome-software at all (only the gnome-software-rpm-ostree plugin is mentioned). It's not part of the acceptance criteria, but it seems like it should be.
Is the current plan to support the PackageKit API in the dnf daemon, or to port packagekit's dnf backend to the dnf5 API?
On Thu, Feb 2, 2023 at 5:42 AM Gordon Messmer gordon.messmer@gmail.com wrote:
On 2023-02-01 13:38, Zbigniew Jędrzejewski-Szmek wrote:
#2870 Change proposal: Replace DNF with DNF5 https://pagure.io/fesco/issue/2870 APPROVED (+6,0,-0)
(Fixed the link above)
The change proposal calls for dnf5 to be ready by the time that F39 is branched, on Aug 8 of this year.
Right now, I don't see any documentation for plugins, the general API docs are (subjectively) terse, and the DNF5 git repo has a banner with warning signs that says "The API/ABI is currently unstable." (...which seems very odd, since 5.0.1 was released in November, so one would expect that the API has been stable since at least that time.)
The change proposal doesn't seem to consider gnome-software at all (only the gnome-software-rpm-ostree plugin is mentioned). It's not part of the acceptance criteria, but it seems like it should be.
Is the current plan to support the PackageKit API in the dnf daemon, or to port packagekit's dnf backend to the dnf5 API?
Well, having it supported in PackageKit is certainly part of the plan once it becomes possible. When that is, I don't know yet...
On 2023-02-02 01:49, Neal Gompa wrote:
Is the current plan to support the PackageKit API in the dnf daemon, or to port packagekit's dnf backend to the dnf5 API?
Well, having it supported in PackageKit is certainly part of the plan once it becomes possible. When that is, I don't know yet...
Does "when it becomes possible" mean "when the API is stable?" Or are there other blocking issues?
Dne 02. 02. 23 v 5:41 Gordon Messmer napsal(a):
The change proposal calls for dnf5 to be ready by the time that F39 is branched, on Aug 8 of this year.
Right now, I don't see any documentation for plugins, the general API docs are (subjectively) terse, and the DNF5 git repo has a banner with warning signs that says "The API/ABI is currently unstable." (...which seems very odd, since 5.0.1 was released in November, so one would expect that the API has been stable since at least that time.)
Right. When Change is proposed it does not need to be done or close to be finished. It is fine.
When the owners submit it, then they indicate that they think it is doable. Fesco agreed that it is doable.
But for the worst case scenario we have
https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5#Acceptance_Criteri...
https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5#Contingency_Plan
And if things will not work out, we can push back and rollback the change. It is hard, but IIRC it happened in past.
The change proposal doesn't seem to consider gnome-software at all (only the gnome-software-rpm-ostree plugin is mentioned). It's not part of the acceptance criteria, but it seems like it should be.
Is the current plan to support the PackageKit API in the dnf daemon, or to port packagekit's dnf backend to the dnf5 API?
This is actually one of the reason the change is happening - rewrite from Python to C. PackageKit is written in C and it was way behind libdnf. And the differences grow over time.
The migration of PackageKit will happen in future for sure. I hope in near future. But if we push on having it in acceptance criteria now then it will be huge step. And it is much easier to do two steps than doing one long step.
Miroslav
On 2023-02-02 08:16, Miroslav Suchý wrote:
Dne 02. 02. 23 v 5:41 Gordon Messmer napsal(a):
Right now, I don't see any documentation for plugins, the general API docs are (subjectively) terse, and the DNF5 git repo has a banner with warning signs that says "The API/ABI is currently unstable." (...which seems very odd, since 5.0.1 was released in November, so one would expect that the API has been stable since at least that time.)
Right. When Change is proposed it does not need to be done or close to be finished. It is fine.
When the owners submit it, then they indicate that they think it is doable. Fesco agreed that it is doable.
Naturally, we want everyone to communicate and organize work in the future. I would never object to that.
My question is whether the proposal accurately describes what will be delivered. Please correct me if I am wrong. As I read it, the change proposal only states that "dnf-3", "yum", and "microdnf", the command-line package management tools, will be replaced with "dnf5". All of the other applications that use libdnf either directly on indirectly (e.g. through PackageKit) will remain in place and continue to be used.
However, the "Benefit to Fedora" section of the proposal strongly implies a different outcome, especially because it promises, "Unified behavior of in the software management stack - Same user experience in workstation, server, containers." If dnf5 is only replacing the command line tool, then the "Benefit to Fedora" and "Major codebase improvements" apply primarily to Fedora containers and servers, while Workstation, Silverblue, and others will actually see larger and more complex installations, and not the smaller, faster, simpler installations that the document promises.
And that also means that the "Problems related to using DNF5 and DNF in parallel for software modification" section applies to Workstation and others; any semblance of integration between the graphical package management stack and "dnf" is lost until sometime in the future when libdnf users are ported. Current state synchronization, transaction history, dependency removal and modules all break if users use any tool other than the "dnf" command line tool. The proposal says so, but I think it understates the number of users who are going to be impacted by that.
On Wed, Feb 1 2023 at 08:41:55 PM -0800, Gordon Messmer gordon.messmer@gmail.com wrote:
Is the current plan to support the PackageKit API in the dnf daemon, or to port packagekit's dnf backend to the dnf5 API?
Red Hat is currently planning to port everything we care about that uses PackageKit to use dnfdaemon's D-Bus API. Currently that's gnome-software, gnome-shell, and gnome-initial-setup. (I think that's all we have in Fedora Workstation that depends on PackageKit?)
I'm not sure this is actually a good plan! If feasible, I'd say the best plan would be for dnfdaemon to implement the same D-Bus API as PackageKit does. Then we no longer need PackageKit to serve as a glue layer, but the PackageKit D-Bus API still lives on as the one true standard for software centers and system updates.
A PackageKit backend for dnf5 would also work and I have no doubt it will happen regardless. Surely that'd be the best option for Fedora if dnfdaemon does not have the same D-Bus API that PackageKit does, because pushing dnf-specific code into upstream projects when PackageKit exists is not very friendly. But Red Hat has a conflicting goal: we don't want to maintain PackageKit anymore!
Michael
Michael Catanzaro wrote:
A PackageKit backend for dnf5 would also work and I have no doubt it will happen regardless. Surely that'd be the best option for Fedora if dnfdaemon does not have the same D-Bus API that PackageKit does, because pushing dnf-specific code into upstream projects when PackageKit exists is not very friendly.
Pushing DNF-specific code is also unlikely to happen for projects such as KDE Plasma Discover, so if we want those to keep working, we will need the PackageKit D-Bus API implemented one way or the other.
But Red Hat has a conflicting goal: we don't want to maintain PackageKit anymore!
I think that if Red Hat drops PackageKit, it will be completely dead. The whole idea of having one common API for all distros has already failed, because many distros have stuck or reverted to defaulting to tools directly using their native package manager / dependency solver. Some of those already emulate the PackageKit D-Bus API.
Even for Fedora, dnfdragora is already used by many users (including me), and now Red Hat wants to port more stuff to dnf5 directly, away from PackageKit. And Fedora is a distribution where PackageKit works *well*. (E.g., I use plasma-pk-updates for my system updates and it just works.) On Arch-based distributions, PackageKit is absolutely horrible (because the PackageKit alpm (pacman) backend is very poorly maintained). E.g., Discover just fails spectacularly at upgrading Manjaro. Only the native tools (pacman, pamac, etc.) work there.
Kevin Kofler
On 2023-02-03 21:49, Kevin Kofler via devel wrote:
Michael Catanzaro wrote:
A PackageKit backend for dnf5 would also work and I have no doubt it will happen regardless. Surely that'd be the best option for Fedora if dnfdaemon does not have the same D-Bus API that PackageKit does, because pushing dnf-specific code into upstream projects when PackageKit exists is not very friendly.
Pushing DNF-specific code is also unlikely to happen for projects such as KDE Plasma Discover, so if we want those to keep working, we will need the PackageKit D-Bus API implemented one way or the other.
Sharing the same point of view, I failed to understand why as open source the community failed to properly produce a better documentation for a plugin and better documentation for a cross platform front package manager like PackageKit while continuing to yet another fragmentation.
Luya Tshimbalanga wrote:
Sharing the same point of view, I failed to understand why as open source the community failed to properly produce a better documentation for a plugin and better documentation for a cross platform front package manager like PackageKit while continuing to yet another fragmentation.
Well, the thing is, PackageKit backends tend to have various bugs and limitations, in part due to impedance mismatch between the designs of PackageKit and of the native package manager (e.g., PackageKit assumes that package manager operations are non-interactive, which is not true for many non-RPM package managers, e.g., dpkg/apt with debconf, alpm/pacman that directly asks the user questions, etc.), in part due to general lack of manpower (mainly because the backends can only really be maintained by people coming from the respective distribution, but distributions typically consider it an upstream PackageKit issue, so nobody feels responsible), and in part because many operations are de-facto optional because different applications need different operations (e.g., Apper was using several operations that no other frontend was using, at least after GNOME-PackageKit was replaced by GNOME Software, so several backends would just not implement those operations, leaving Apper badly broken, and eventually leading to it getting abandoned upstream as well).
Those limitations were even seen in Fedora (which has relatively good PackageKit support), e.g., I remember the issues with Apper due to several operations only Apper was using simply not getting implemented in the then- latest backend rewrite (IIRC, the hif backend that replaced the yum backend at the time). But there are other backends that are in a much worse state.
When distribution developers and users encounter these limitations, the first suggestion that keeps coming up is always to just drop the "broken" middleman (PackageKit) and use the native tools directly. After all, many distributions have existing software using the native tools, which tends to still just work, even on those distros that had neglected them (in favor of PackageKit-based tools) for years. (Fedora is a bit of a special case in that the native tools change so often that frontends struggle keeping up, e.g., Yumex was eventually discontinued, was dead for years, and is now being rewritten from scratch. Other distributions are much more conservative in their package management tooling, so their native frontends do not break so often. That makes it much less appealing for them to rely on an abstraction layer such as PackageKit.)
So, the answer to why "continuing yet another fragmentation" is that the "fragmented" tools tend to just work whereas PackageKit often does not. E.g., many backends including the current Fedora ones have only very limited support for package-level enumeration (e.g., no group browsing, limited or no dependency and reverse dependency querying, etc.) because all the current frontends (GNOME Software, KDE Plasma Discover) rely on AppStream metadata instead (which by design does not include all packages and which also by design does not support things such as enumerating reverse dependencies). That in turn makes it impossible to resurrect frontends such as Apper (or implement new ones) that would offer those features. (It is a vicious circle because frontends cannot offer the features if the backends do not implement them, and the backends do not implement them because no frontend uses them.) So users naturally turn to alternatives such as Dnfdragora on Fedora, Synaptic on Debian/Ubuntu, Pamac-GTK on Arch/Manjaro, etc. (or even the raw native CLI tools) which offer those low-level package operations that the PackageKit frontends and backends do not implement. But even operations that are supposed to be supported, such as updating the system with Discover (or GNOME Software or plasma-pk-updates or even the pkcon CLI, they all use basically the same APIs for system updates), fail to work on some distributions because some backends are just broken (e.g., the alpm/pacman one). There too, users turn to native tools (in this case, pacman CLI, pamac CLI, or pamac-gtk) as the obvious alternative.
So, to conclude, documentation is not what is missing in PackageKit. Backend maintenance is, as is a perceived benefit (from a distribution developer's and/or end user's point of view) over just using (typically already existing) native tools.
Kevin Kofler
On 2023-02-02 09:33, Michael Catanzaro wrote:
Red Hat is currently planning to port everything we care about that uses PackageKit to use dnfdaemon's D-Bus API. Currently that's gnome-software, gnome-shell, and gnome-initial-setup. (I think that's all we have in Fedora Workstation that depends on PackageKit?)
Are there any plans to provide the gstreamer or gtk plugins that automatically install codecs and fonts that are missing? (https://github.com/PackageKit/PackageKit/tree/main/contrib)%C2%A0 Or are those features just going away?
A PackageKit backend for dnf5 would also work and I have no doubt it will happen regardless. Surely that'd be the best option for Fedora if dnfdaemon does not have the same D-Bus API that PackageKit does, because pushing dnf-specific code into upstream projects when PackageKit exists is not very friendly. But Red Hat has a conflicting goal: we don't want to maintain PackageKit anymore!
Has anyone asked freedesktop.org if there are developers interested in maintaining it there? It certainly seems like something that fits in the category of "Desktop middleware and frameworks".
On Sat, Feb 4 2023 at 02:05:16 PM -0800, Gordon Messmer gordon.messmer@gmail.com wrote:
Are there any plans to provide the gstreamer or gtk plugins that automatically install codecs and fonts that are missing? (https://github.com/PackageKit/PackageKit/tree/main/contrib) Or are those features just going away?
I guess that's up to dnf team. I assume they'll go away.
I'd be pretty surprised if they even work properly. It's not like Fedora has the codecs you want anyway.
Has anyone asked freedesktop.org if there are developers interested in
maintaining it there? It certainly seems like something that fits in the category of "Desktop middleware and frameworks".
I meant we don't want to maintain it downstream anymore. github.com vs. freedesktop.org doesn't make any difference.
Michael