Following up advices to my other question I have set up my local RPM repository on Red Hat 8 machine, placed my private packages in there and am now able to install, update etc.

However, there is a problem: one package I added in my private repository, is actually a modified version of the package available in the official RedHat repositories, and has the same name. So yum search or yum install would pull the package from the official mirror, not mine. I tried to solve this with yum --repo=my_private_repo ... but this would also try to pull all the dependecies from my_private_repo instead of the official ones.

What could be the right way to solve this? May be the better option would be to rename the package (the one I modified and added in my repository), so that it does not conflict with the official one?

Would appreciate any advices!

1 Answer 1


Replacing packages from EL baseos or appstream repos is tricky. Nightmare dependency problems can happen when you replace what the distro was expecting with something else. This is one of the reasons the EL community dislikes certain third party repos.

Find a repo doing sane things and examine what they do to their packages. IUS is an example. All of these need to be true to be safe:

Most IUS packages are safe replacement packages. This is a term we use to describe packages with the following properties.

  • Replaces the functionality of a stock package.
  • Uses a different name than the stock package to prevent unintended upgrades.
  • Provide the stock package name to satisfy the dependencies of other packages.
  • Conflict with the stock package.
  • Must not obsolete any stock packages.

So for example rather than just "haproxy" you could install "haproxy22". Which is a name only IUS provides, but replaces the appstream one:

Name:           haproxy22

Provides:       haproxy = %{version}-%{release}
Provides:       haproxy%{?_isa} = %{version}-%{release}
Conflicts:      haproxy < %{version}-%{release}

Note you do want to rpm Conflict with the stock package, so dnf will not consider it.

This scheme requires a higher version release number than stock. Consider increasing the release number by a lot.

See also Fedora Packaging Guidelines for resources.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .