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 <vondr...@redhat.com> 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@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 > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue >
-- _______________________________________________ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
