0

I have an installation of an RPM-based distro (like Fedora), which uses one set of RPM repositories for its packages, and I'd like to change it to instead use a different set of RPM repositories, effectively transforming it into another distro (like CentOS). I would need to do this without reinstalling the system wholesale.

The reason I'd like to do this is because this machine has been given to me by my organization, and we were told "not to install any other OS" on it. However, it's using an obscure set of repos, which seem to be rather slow to pick up security updates, and I can't really trust that repo to be properly maintained. I do have root access on the machine, and according to the IT department this would not count as "reinstalling".

However, this repo has packages for which the version name has a vendor suffix (like, for example, a package from Ubuntu having a version of 1:13.0.1-2ubuntu2). In particular, certain system packages like systemd have that. AFAICT, this means that everything that depends on systemd, as well as systemd itself, will have to be reinstalled, and so most of the system will be deleted and then reinstalled while the system is running, which seems like a very quick way to break my installation.

One possible solution I've considered is: starting from the leaves of the dependency tree of my installation,

  • download the corresponding package from the new repo
  • edit it so that its dependency versions match the old repo's
  • install this package over the existing one
  • if this package was depended on by any other packages, replace those with their unedited version (because this package now has the new name, and the edited packages were depending on the old name)
  • sequentially do this for every depth of the dependency tree

Would this strategy work, and what other options do I have to perform such an upgrade?

Improve this question

1 Answer 1

Reset to default
0

  1. The part 2ubuntu2 is called the Release number. The package manager uses it to compare two variants of a package with the same version. And the package manager treats it purely alphanumeric. No other semantics. The part ubuntu2 is called dist-tag. It is used to help humans for which system the package is intended. But the package manager does not evaluate the value. You can install 'el5' package on RHEL9 and 'el9' on RHEL5. Usually, the package requirements stop you. But if your package has no other dependency, then you can do it. And there is nothing wrong with this approach.

  2. The RPM packages are upgraded in a way that the new one is installed, and only then the old one is removed. So even if you do dnf upgrade, then the system should be operational all the time. Even during the transaction.

  3. The dependencies are so complicated that upgrading packages one by one will be close to impossible. You will have better luck doing it in one big transaction.

  4. Taking files from /etc/yum.repos.d from CentOS and putting in your machine in /etc/yum.repos. and doing dnf upgrade or dnf distro-sync will likely do the work. I would say there is an 80 % chance that it will work. But that remaining 20 % is nasty. In the better case, you get broken dependencies before the transaction. You may resolve it somehow. In the worst case, you get some errors during the transaction. And everything breaks down and you get an unbootable system. Hard to guess in advance. The thing is that you will likely be the first one in the world doing this. And such pioneers will discover bugs.

I would be very hesitant to do this with a production machine. At least you should first try this upgrade path on some virtual machine of the same configuration.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.