Re: What is DNF Check-upgrade Actually Doing

[Will McDonald <wmcdonald@xxxxxxxxx>]

On Mon, 25 Nov 2024 at 22:23, Stephen Morris <steve.morris.au@xxxxxxxxx> wrote:

With the explanation of what dnf is doing, if an end used runs the dnf clean command with whatever obligatory sub-command they chose will their repositories lose all knowledge of what packages have been updated, or will dnf update/upgrade refresh that data irrespective of whether --refresh is specified or not?

I don't want to assume on your behalf. But you might be conflating/confusing the repository metadata with the DNF's local state and/or the RPM database history. 

If you've only ever used DNF / Yum to manage boxes without needing to look at what RPM does I can see why you might worry. Nowadays it's probably very easy to manage systems with dnf/yum and not really have to dig into their interface into the underlying RPM stuff.

Repo metadata is this stuff: https://blog.packagecloud.io/yum-repository-internals/

It's hosted remotely with the repositories, mirrored locally for speed when cache expires and is pretty much entirely throwaway, because you can (normally) always get a refreshed copy from the remote repository.

"knowledge of what packages have been updated" is open to interpretation. What's been updated/available *in the upstream repositories* is entirely in that "remote" repository metadata.

What's been updated *on a local system,* is separate, distinct. I would guess that the source of truth here would be the rpmdb, maybe with a scattering of DNF data sources for speed, I've not looked into it in any detail.

The dnf5 man page states:

FILES
       Cache Files
              /var/cache/libdnf5/

       Main Configuration
              /etc/dnf/dnf.conf

       Repository Configuration
              /etc/yum.repos.d/

       Repository Persistence
              /var/lib/dnf/

       System State
              /usr/lib/sysimage/libdnf5/

I would hazard a guess that the DNF history is coming from System State?

[vagrant@localhost ~]$ tree /usr/lib/sysimage/
/usr/lib/sysimage/
├── libdnf5
│   ├── comps_groups
│   │   ├── cloud-bootloader-tools.xml
│   │   ├── cloud-server-environment.xml
│   │   ├── cloud-server.xml
│   │   ├── container-management.xml
│   │   └── core.xml
│   ├── environments.toml
│   ├── groups.toml
│   ├── modules.toml
│   ├── nevras.toml
│   ├── packages.toml
│   ├── system.toml
│   ├── transaction_history.sqlite
│   ├── transaction_history.sqlite-shm
│   └── transaction_history.sqlite-wal
└── rpm
    ├── rpmdb.sqlite
    ├── rpmdb.sqlite-shm
    └── rpmdb.sqlite-wal

4 directories, 17 files

I'd go poke around in these locations (in a test VM or container), read some man pages and maybe skim some of the project docs to understand more if it's something you feel you really need to know inside out? Possibly (and again, apologies if you already have, don't want to assume) but if you haven't done much directly with RPM, mess about with that to understand the separation between RPM and Yum/DNF?

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