The thing is that dnf does not alter downloaded repository metadata in any way. So we cannot create a subset of metadata with only the newest packages.
But I agree that the current behavior is confusing. There are two solutions I can think of:
- make `-n` and `--download-metadata` options mutually exclusive and error out when used together (I'd prefer this). User then must use createrepo_c to make a repo from downloaded packages.
- just print warning for the user that the repo is not directly usable (but reposync prints a lot of output and the warning might get lost in it)

The behavior is confusing, but from my experiments I don't see any issue with having too many informations in the metadata, this doesn't seem to affect package installation at all.

Hi Marek,

The real issue is more with `reposync -n --download-metadata` not "fixing" the metadata to reflect what is currently in the repository.

For example, let's assume "glib2" is currently installed on the system at level 2.56.4-156.el8 and latest available is "glib2-2.56.4-158.el8".
After doing a "reposync ...", installing "gimp-devel" package will fail:
~~~
# dnf install --disablerepo="*" --repofrompath mntos,file:///mnt/os --repofrompath mntapp,file:///mnt/app-os gimp-devel
...
Installing:
 gimp-devel                    x86_64          2:2.8.22-15.module+el8+2760+3d7d61b2             mntapp          940 k
Installing dependencies:
...
 glib2-devel                   x86_64          2.56.4-156.el8                                   mntos           424 k
...

Is this ok [y/N]: y
Downloading Packages:
Error opening /mnt/os/Packages/g/glib2-devel-2.56.4-156.el8.x86_64.rpm: No such file or directory
~~~

This is because "glib2-devel-2.56.4-156.el8" is not present in the repository (since it only has latest).
Upon resolving the transaction, because "glib2-2.56.4-156.el8" is already installed, dnf will try to install corresponding "glib2-devel-2.56.4-156.el8" which doesn't exist in the repository.

NOW, if you update the metadata, the issue disappears because dnf is smart enough to update "glib2" to solve the dependencies:
~~~
# createrepo --update /mnt/os
Directory walk started
Directory walk done - 1789 packages
...

# rm -fr /var/cache/dnf

# dnf install --disablerepo="*" --repofrompath mntos,file:///mnt/os --repofrompath mntapp,file:///mnt/app-os gimp-devel
...
Installing:
 gimp-devel                    x86_64          2:2.8.22-15.module+el8+2760+3d7d61b2             mntapp          940 k
Upgrading:
 glib2                         x86_64          2.56.4-158.el8                                   mntos           2.5 M
Installing dependencies:
...

Is this ok [y/N]: y
Downloading Packages:
Running transaction check
Transaction check succeeded.
...
~~~

This is where improvement can happen: upon using "-n --download-metadata", an automatic "createrepo --update" should be performed, or a message telling the user to do so printed.

Renaud.

Thanks Renaud,
Yes I'd vote for spawning an extra 'createrepo --update' process when using both '-n --download-metadata' options, rather than bailing out completely here.
It would be much more end-user friendly here.
My 5 cents.

Thanks guys for adding the third option. I'm just wondering if it wouldn't be better to have separate explicit option for spawning createrepo on downloaded content (e.g. `--createrepo`). I'm worried about changing the reposync behavior in the middle of RHEL 8 life cycle. Adding a new option will be safer from this point of view.

Well, I think it might have some sense but then it is questionable if it still makes a sense to keep the --download-metadata option.
I am using --download-metadata (rather than running createrepo) because I am do not want to lose information about groups/modules etc (not sure if createrepo can fully recreate repository w/o losing any such information).
Maybe it would make a sense to introduce new option "--createrepo" to spawn "createrepo --update" when flag --download-metadata is also used, otherwise we would only spawn "createrepo" to create a fresh new metadata. Does it make a sense?

I created a PR with update of documentation - https://github.com/rpm-software-management/dnf-plugins-core/pull/483

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (dnf-plugins-core bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:7125