Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
There exists a parameter 'enabled_metadata' with very scarce information over upstream or internet for that matter.
Only information available is one liner on fedora doc:
~~~
The repo file has the setting enabled_metadata=1. This means that some tools can optionally retrieve the metadata from this repository to provide a list of its contents to the user. The option is not used by yum or dnf.
~~~
https://fedoraproject.org/wiki/Third_Party_Repository_Policy
We have a Fedora BUG 1569862, won't fix closed.
https://bugzilla.redhat.com/show_bug.cgi?id=1569862
Version-Release number of selected component (if applicable):
[plawate@plawate dnf]$ cat /etc/redhat-release
Red Hat Enterprise Linux release 8.7 (Ootpa)
[plawate@plawate dnf]$ rpm -q dnf
dnf-4.7.0-11.el8.noarch
How reproducible:
100%
Steps to Reproduce:
1. 2. Search for "enabled_metadata"
Actual results:
Parameter is not described in the man page.
Expected results:
Parameter should be described in the man page.
Additional info:
Fedora uses this parameter in a repo that we ship in the default installation but it's not documented.
That's why I consider this as a *UX (user expierence) bug* and, in my opinion, this ticket should be re-opened and fixed.
Instead of having a mysterious parameter in the configs and provide no option for the user to find out what it does, we should do one of the following:
1) Do not use this parameter in any repo.
2) Document the parameter in the man page. The description can mention that dnf does not use this parameter, but other tools can use it to optionally retrieve the metadata from the repository to provide a list of its contents to the user.
> The repo file has the setting enabled_metadata=1. This means that some tools can optionally retrieve the metadata from this repository to provide a list of its contents to the user. The option is not used by yum or dnf.
Yes it is true.
However, it is an interesting approach to describe in the DNF documentation a configuration parameter that can be used by other applications, but DNF itself does not use the "enable_metadata" parameter and does not even know about its existence.
The value is unused by DNF (cannot be used by dnf) therefore we can close the bug report or we can document it as unused by dnf. I would recommend to close it in favor of other work.
The configuration is used by `packagekit`.
Hello Jaroslav,
I will probably create a KCS for notifying customers asking for this. The number of customers who would want this is pretty low so I guess we can skip this in favor something important that warrants prioritization.