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.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
