6:09 a.m.
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.
3:38 p.m.
New subject: Summary/Minutes from yesterday's FESCo Meeting (2023-02-07)
= 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...
Minutes (text):
https://meetbot.fedoraproject.org/fedora-meeting/2023-01-31/fesco.2023-01...
Log:
https://meetbot.fedoraproject.org/fedora-meeting/2023-01-31/fesco.2023-01...
= 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)
10:41 p.m.
New subject: Will dnf5 be ready by F39?
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?
https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5
3:49 a.m.
New subject: Will dnf5 be ready by F39?
On Thu, Feb 2, 2023 at 5:42 AM Gordon Messmer <gordon.messmer(a)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?
https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5
Well, having it supported in PackageKit is certainly part of the plan
once it becomes possible. When that is, I don't know yet...
--
真実はいつも一つ！/ Always, there's only one truth!
1:39 p.m.
New subject: Will dnf5 be ready by F39?
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?
>
> https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5
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?
10:16 a.m.
New subject: Will dnf5 be ready by F39?
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_Crit...
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
3:12 p.m.
New subject: Will dnf5 be ready by F39?
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.
11:33 a.m.
New subject: Will dnf5 be ready by F39?
On Wed, Feb 1 2023 at 08:41:55 PM -0800, Gordon Messmer
<gordon.messmer(a)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
11:49 p.m.
New subject: Will dnf5 be ready by F39?
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
7:26 p.m.
New subject: Will dnf5 be ready by F39?
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
Fedora Design Team
Fedora Design Suite maintainer
8:31 p.m.
New subject: Will dnf5 be ready by F39?
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
4:05 p.m.
New subject: Will dnf5 be ready by F39?
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) 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".
10:54 a.m.
New subject: Will dnf5 be ready by F39?
On Sat, Feb 4 2023 at 02:05:16 PM -0800, Gordon Messmer
<gordon.messmer(a)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
443
days inactive
448
days old
12 comments
7 participants
participants (7)
-
Gordon Messmer -
Kevin Kofler -
Luya Tshimbalanga -
Michael Catanzaro -
Miroslav Suchý -
Neal Gompa -
Zbigniew Jędrzejewski-Szmek