Hello Vit,
I don't understand this. So if GS going to use DNF, therefore the same cache etc, or not? Or what other metadata PackageKit downloads on top of DNF?
Yes, it will ultimately utilize the same cache. The paragraph you referenced is extracted from the "Early access for developmental branch users" section. This means that until integration is finalized, GNOME Software will use the libdnf backend, which can operate alongside dnf5 but maintains a separate cache. I'll revise the wiki paragraph to explicitly state this as a temporary arrangement until integration is complete.
Previously, I had issues that migration from DNF4 to DNF5 left a lot of data in /var/cache. How is this going to be addressed? I don't think it is fair to leave those behind and waste disk space for regular users.
That's a good point. Though since this migration isn't entirely removing dnf4 from the system but just altering the symlink, users can still access it. Hence, automated removal isn't feasible. However, we could consider offering a user prompt after the transaction involving symlink replacement, advising users to delete /var/cache/dnf if they no longer intend to use dnf4.
Thanks,
Jan
On Mon, Mar 25, 2024 at 5:59 PM Vít Ondruch <vondruch@xxxxxxxxxx> wrote:
--
Dne 25. 03. 24 v 16:46 Aoife Moloney napsal(a):
=== Reduced footprint === The dnf5 package is a fully-featured package manager that doesn't require Python dependencies. It also reduces the number of software management tools in Fedora by replacing both the dnf and microdnf packages. The installation size of the dnf5 stack in an empty container is approximately 60% smaller than the dnf installation. Currently, dnf, microdnf, and PackageKit use their own cache, leading to significant metadata redundancy. With dnf5 and dnf5daemon, which share metadata, this redundancy will be eliminated.
... snip ...
===== [https://github.com/rpm-software-management/dnf5/issues/169 GNOME Software support] ===== The integration of dnf5 support, particularly dnf5daemon, into GNOME Software is currently underway. Developers from both DNF5 and GNOME Software are closely connected and regularly synchronize the progress of their work.
... snip ...
===== GNOME Software ===== Rawhide users will continue to utilize the current PackageKit backend connected to the existing libdnf interface. These libraries can coexist with the new dnf5 package on the same system. Although the setup is not ideal due to differences in package state metadata formats stored at separate locations, resulting in inefficient storage usage, this is generally imperceptible for typical GUI users. Furthermore, the underlying RPM DB remains the sole shared source of information about installed packages.
I don't understand this. So if GS going to use DNF, therefore the same cache etc, or not? Or what other metadata PackageKit downloads on top of DNF?
==== Before upgrade ==== <pre> $ tree /usr/bin/ -P dnf* /usr/bin/ ├── dnf -> dnf-3 ├── dnf-3 └── dnf4 -> dnf-3 </pre> ==== After upgrade ==== <pre> $ tree /usr/bin/ -P dnf* /usr/bin/ ├── dnf -> dnf5 ├── dnf-3 ├── dnf4 -> dnf-3 └── dnf5 </pre>
<sarcasm>
Love these versions, as always
</sarcasm>
=== Different system state === The transactional history in dnf and dnf5 is not shared, and they now use different formats. Transactions performed in dnf will not be visible in dnf5, and vice versa. While the history database is not migrated to dnf5, when running a transaction in dnf5 for the first time, an attempt is made to convert and load the existing system state from dnf. This should preserve information about the reasons for installed packages and prevent them from being treated as user-installed, requiring manual removal from the system instead of being seen as dependencies of explicitly removed packages.
Previously, I had issues that migration from DNF4 to DNF5 left a lot of data in /var/cache. How is this going to be addressed? I don't think it is fair to leave those behind and waste disk space for regular users.
Vít
_______________________________________________
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
-- _______________________________________________ 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
