F45 Change Proposal: Relocate Rpm Repo Configs To Usr [SelfContained]

Project Discussion Change Proposals
, ,
1

Relocate Rpm Repo Configs To Usr

Wiki

Announced

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Summary :open_book:

Relocate all packaged RPM repository configuration data from /etc to /usr.

Owner :open_book:

Detailed Description :open_book:

This Change aims relocate all packaged RPM repository configuration data from /etc/yum.repos.d to /usr/share/dnf5/repos.d. All Fedora packaging PGP/GPG keys in fedora-gpg-keys will also be relocated to /usr/share/pki/rpm-gpg.

This is now possible because all major read+write frontends for DNF configuration now go through DNF5. Fedora has now switched to DNF version 5 in the build system ([[Changes/BuildWithDNF5|Fedora Linux 40]]), the user-facing CLI tools ([[Changes/SwitchToDnf5|Fedora Linux 41]]), the installer ([[Changes/Switch_Anaconda_installer_to_DNF5|Fedora Linux 43]]), and PackageKit ([[Changes/PackageKit-DNF5|Fedora Linux 44]]). This means all the major supported entry points implicitly support DNF5’s layered configuration system.

The fedora-third-party tool used by Fedora KDE Plasma variants and Fedora Workstation will also be adjusted for this new world.

Feedback :open_book:

Benefit to Fedora :open_book:

The key benefit for Fedora is it establishes a clean separation of packaged repository definitions and allows for users to trivially identify local changes and undo them if desired. This is also necessary to simplify how derivatives handle repository definitions, since moving it to /usr allows the middle layer for packaged repository configuration overrides to function properly.

Scope :open_book:

  • Proposal owners:
    ** {{package|fedora-repos}}: Relocate yum.repos.d and rpm-gpg data to new locations in /usr
    ** {{package|fedora-workstation-repositories}}: Relocate yum.repos.d and rpm-gpg data to new locations in /usr
    ** {{package|fedora-third-party}}: Update configuration editor code to generate drop-in files in /etc/dnf/repos.override.d
  • Other developers: N/A (not needed for this Change)
  • Release engineering: [Making sure you're not a bot! #13321]
  • Policies and guidelines: N/A (not needed for this Change)
  • Trademark approval: N/A (not needed for this Change)
  • Alignment with the Fedora Strategy: N/A (not needed for this Change)

Upgrade/compatibility impact :open_book:

Distribution provided RPM repository configuration files, if unmodified, will cleanly move from /etc to /usr. If modified, they will stay in place and override the configuration files shipped in /usr entirely.

Going forward, packaged repository configuration will no longer be present in /etc.

Early Testing (Optional) :open_book:

N/A

How To Test :open_book:

Once the changes are made in Rawhide, simply upgrade into them and interact with the package manager normally.

User Experience :open_book:

There should be no substantially visible changes to the user experience.

Dependencies :open_book:

  • {{package|fedora-repos}}
  • {{package|fedora-workstation-repositories}}
  • {{package|fedora-third-party}}

Contingency Plan :open_book:

  • Contingency mechanism: Rollback and defer to the next release
  • Contingency deadline: Final Freeze
  • Blocks release? Yes

Documentation :open_book:

DNF5 documentation on the configuration system: DNF5 Configuration Reference — dnf5 documentation

Release Notes :open_book:

Fedora Linux 45 now ships all distribution-provided configuration for the DNF package manager in /usr, which makes it easier to identify user-local changes in /etc separately from distribution-provided configuration.

Last edited by @alking 2026-04-23T16:37:15Z

Last edited by @alking 2026-04-23T16:37:15Z

1 Like
2

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply give that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

3

I still use dnf4 makecache for some tasks. How will this change impact that? (I don’t think we need to keep dnf 4 forever, but as long as we do, we should not break it.)

4

We can teach DNF version 4 to read all the other directories. But it would not be safe to manipulate the configuration with DNF4.

But, what are you using dnf4 makecache for? The cache directory is different for dnf4 and dnf5, so you should be using dnf5 makecache in that case.

5

I use it for Making sure you're not a bot! — that can probably be migrated to dnf5. But that’s not my point. I think that if we want to make this change, we need to fix dnf 4 as well.

6

I’m in favor of this change but damned, that’s going to break so many habits and scripts and docs, etc.

We should make sure to document the proper commands to disable a repo in /usr without doing a sed, etc.

7

As I recall, Silverblue (as an immutable OS) makes /usr read-only. The current instructions for adding 3rd party repos (and coprs) include updating the files in /etc/yum.repos.d/ and performing an rpm-ostree refresh-md (apologizes if my memory is wrong/hazy). How will this all work if the repo definitions are in the (read-only) /usr filesystem?

8

User-added repositories through dnf copr and dnf config-manager will get stored in /etc/yum.repos.d as always. This only changes repositories delivered through RPMs.

9

Somehow that was not clear to me that /etc/yum.repos.d/ will still be usable (and my finger muscle memory will not always need to be retrained).

So dnf config-manager --set-disabled=repo will create any overrides in /etc (copying the appropriate stanzas from /usr)? Thanks.

10

It uses another folder (Config-manager Command — dnf5 documentation):

setopt [–create-missing-dir] <[repoid.]option_name=value>+

…
The repositories configuration is read from the repository configuration files and then adjusted using repository configuration overrides. Repository configuration override files are read from the distribution repository override directory (/usr/share/dnf5/repos.override.d) and from the system repository override directory (/etc/dnf/repos.override.d). If a file with the same name is present in both override directories, only the file from the system override directory is used. Thus, the distribution override file can simply be masked by creating a file with the same name in the system override directory. All used override files are sorted alphabetically by their names and then applied in that order. The override from the next file overwrites the previous one—the last override wins.
…

11

Definitely needs good advertisement.

I’m so used to file edits that I found out about the overrides only because my conf edit did not work any more (either for updates-testing during freeze, or h264 or such). Tinkerers are more used to text config edits than looking up config-manager commands :innocent:

1 Like
12

I don’t understand why /etc/dnf5.repos.d/ was not a viable option.

I don’t understand what’s the purpose of /etc going forward.

Randomly plucking things from /etc and throwing it to /usr/share - not even /usr/share/etc/ for some semblance of consistency - seems like self inflicted pain.

@mjg is right about one thing: The only occasions I may have used tools like config-manager would have been if copy pasting something. Otherwise digging into /etc would have been enough.

Seems like with F45+ we’ll have more headaches either troubleshooting old installations or setting up new ones. Bummer :neutral_face:

13

The separation between /usr and /etc can make sense, even if we’re not quite there yet:

  • /usr is for system installed config
  • /etc is for local config and overrides

Having /usr mostly immutable (outside of package updates) is good on a mutable system, to. For example, you need to back-up /etc only because /usr can be reinstalled. OTOH, no update will overwrite what you have in /etc , and if you’re wondering about something in there you’ll know whom to blame :wink:

6 Likes
14

I also think that this Change needs to account for dnf4 by either updating the config parser code in dnf/libdnf to account for the new directories and overrides (strongly preferred) or at least acknowledge in the compatibility impact section that this’ll break usage of python3-dnf that relies on loading system repositories.

15

Certainly can update it to indicate that DNF4 stuff won’t be able to work for system repositories.

16

I’m in favour of this.

17

I’ve added this the compatibility impact:

Legacy RPM package managers (like DNF version 4, YUM, etc.) will not function as system package managers anymore, since the configuration will largely not exist for them anymore.

18

I am definitely in favor of this change. My dream is to have an atomic system with an empty /etc :slightly_smiling_face:

It seems after this change we will be able to define new repositories in these directories:

  1. /etc/yum.repos.d
  2. /etc/distro.repos.d
  3. /usr/share/dnf5/repos

And we will be able to define overrides in these directories:

  1. /usr/share/dnf5/repos.override.d
  2. /etc/dnf5/repos.override.d

The system administrator would define their own custom repos in /etc/yum.repos.d as usual but if they wanted to change an option for an existing repo then they would create a new file in /etc/dnf5/repos.override.d. (or just use dnf config-manager anyway)

I guess this may break scripts which edit file repos in-place but from the perspective of the administrator it seems mostly transparent.

19

So how would overrides work? Would it be the same as systemd where only the line you want to add or change would need to be in the config file?
This isn’t a small change, and would need lots of advertisement beforehand if it’s to be successful.

1 Like
20

The idea seems fine, but it feels to me it could be worth expanding the release notes a bit. It could note the complete paths involved, and also mention the override mechanism with a pointer to the manual page.

1 Like