Add the possibility to load filelists conditionally

[jan-kolarik]

• Read new optional_metadata_types configuration option from libdnf
• Request filelists metadata by individual commands
• Add heuristics to detect filename patterns in spec arguments

Overall, the behavior introduced here is taken from the existing implemention in DNF5 (see this PR).

Currently, the changes should not introduce any new behavior by default. The introduction of dropping the filelists loading by default should come after the system-wide change proposal is accepted.

Requires changes from: rpm-software-management/libdnf#1635.

Related:

• Add a hint for user on transaction file dependency failure #2026
• Request filelists metadata for plugins needing that dnf-plugins-core#517

Targetted for: https://issues.redhat.com/browse/RHEL-12355.

[m-blaha]

Although according to packaging guidelines there should not be file dependencies out of '/etc', '/usr/bin/', and '/usr/sbin' (see https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_directory_dependencies), there still are such packages in F39:

kata-containers-3.0.1-1.fc38.1.x86_64
   /usr/libexec/virtiofsd
mod_nss-1.0.17-18.fc39.x86_64
   /usr/lib64/libnssckbi.so
mpibash-mpich-examples-1.3-16.fc39.x86_64
   /usr/lib64/mpich/bin/mpibash_mpich
mpibash-openmpi-examples-1.3-16.fc39.x86_64
   /usr/lib64/openmpi/bin/mpibash_openmpi
rt-5.0.4-2.fc39.noarch
   /usr/share/fonts/google-droid-sans-fonts/DroidSans.ttf
   /usr/share/fonts/google-droid-sans-fonts/DroidSansFallbackFull.ttf
scalasca-mpich-2.6.1-2.fc38.x86_64
   /usr/lib64/mpich/bin/scorep-config
scalasca-openmpi-2.6.1-2.fc38.x86_64
   /usr/lib64/openmpi/bin/scorep-config
sqlninja-0.2.999-0.20.alpha1.fc39.noarch
   /usr/share/sqlninja/backscan.pl
   /usr/share/sqlninja/bruteforce.pl
   /usr/share/sqlninja/dirshell.pl
   /usr/share/sqlninja/dns.pl
   /usr/share/sqlninja/escalation.pl
   /usr/share/sqlninja/fingerprint.pl
   /usr/share/sqlninja/getdata.pl
   /usr/share/sqlninja/icmp.pl
   /usr/share/sqlninja/metasploit.pl
   /usr/share/sqlninja/resurrectxp.pl
   /usr/share/sqlninja/revshell.pl
   /usr/share/sqlninja/session.pl
   /usr/share/sqlninja/sqlcmd.pl
   /usr/share/sqlninja/test.pl
   /usr/share/sqlninja/upload.pl
   /usr/share/sqlninja/utils.pl
rt-5.0.5-2.fc39.noarch
   /usr/share/fonts/google-droid-sans-fonts/DroidSans.ttf
   /usr/share/fonts/google-droid-sans-fonts/DroidSansFallbackFull.ttf

What's the plan for these packages which will become uninstallable? Should we at least file a bug on them to fix their dependencies?

[jan-kolarik]

Although according to packaging guidelines there should not be file dependencies out of '/etc', '/usr/bin/', and '/usr/sbin' (see https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_directory_dependencies), there still are such packages in F39:

kata-containers-3.0.1-1.fc38.1.x86_64
   /usr/libexec/virtiofsd
mod_nss-1.0.17-18.fc39.x86_64
   /usr/lib64/libnssckbi.so
mpibash-mpich-examples-1.3-16.fc39.x86_64
   /usr/lib64/mpich/bin/mpibash_mpich
mpibash-openmpi-examples-1.3-16.fc39.x86_64
   /usr/lib64/openmpi/bin/mpibash_openmpi
rt-5.0.4-2.fc39.noarch
   /usr/share/fonts/google-droid-sans-fonts/DroidSans.ttf
   /usr/share/fonts/google-droid-sans-fonts/DroidSansFallbackFull.ttf
scalasca-mpich-2.6.1-2.fc38.x86_64
   /usr/lib64/mpich/bin/scorep-config
scalasca-openmpi-2.6.1-2.fc38.x86_64
   /usr/lib64/openmpi/bin/scorep-config
sqlninja-0.2.999-0.20.alpha1.fc39.noarch
   /usr/share/sqlninja/backscan.pl
   /usr/share/sqlninja/bruteforce.pl
   /usr/share/sqlninja/dirshell.pl
   /usr/share/sqlninja/dns.pl
   /usr/share/sqlninja/escalation.pl
   /usr/share/sqlninja/fingerprint.pl
   /usr/share/sqlninja/getdata.pl
   /usr/share/sqlninja/icmp.pl
   /usr/share/sqlninja/metasploit.pl
   /usr/share/sqlninja/resurrectxp.pl
   /usr/share/sqlninja/revshell.pl
   /usr/share/sqlninja/session.pl
   /usr/share/sqlninja/sqlcmd.pl
   /usr/share/sqlninja/test.pl
   /usr/share/sqlninja/upload.pl
   /usr/share/sqlninja/utils.pl
rt-5.0.5-2.fc39.noarch
   /usr/share/fonts/google-droid-sans-fonts/DroidSans.ttf
   /usr/share/fonts/google-droid-sans-fonts/DroidSansFallbackFull.ttf

What's the plan for these packages which will become uninstallable? Should we at least file a bug on them to fix their dependencies?

Yeah I guess this is a good topic for discussion for our next team meeting. The problem that was already mentioned in the change proposal discussion is that the rule is of SHOULD NOT matter, which means that having such dependencies might be acceptable with a valid excuse. Therefore, we should be aware that there could always be some of these packages present.

It would be great to at least provide users with a hint in case of failures without filelists. However, I'm not certain if this is currently feasible without making changes to the solver.

[jan-kolarik]

@m-blaha I forgot to mention that there is already an existing bug tracking these issues, and there are submissions for individual packages.

[m-blaha]

@m-blaha I forgot to mention that there is already an existing bug tracking these issues, and there are submissions for individual packages.

Oh great, I didn't know about it. In that case consider my comment irrelevant :)

[j-mracek]

LGTM - the last simplification was really great idea. There is a related comment - rpm-software-management/libdnf#1635 (comment)

This PR cannot be merged without modification of Requires: python3-hawkey version

[j-mracek]

LGTM, CI passed locally.