On Mon, 25 Nov 2024 at 22:23, Stephen Morris <steve.morris...@gmail.com>
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@lists.fedoraproject.org
To unsubscribe send an email to users-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/users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to