-
|
Hello, I know that
but this issue appear in other distro so it might not be specific to a vendor + I am willing to contribute (in code and/or debug). I debugged myself without success. I have the exact same issue that this guy: https://forums.oracle.com/ords/apexds/post/upgrade-ol7-ol8-with-leapp-vs-epel-2539 I tried to fill to_remove, to_install but doesn't seems/know if it get read/used. This person might have same issue (because it refer to the same link): https://talk.plesk.com/threads/upgrade-centos-7-9-to-alma-linux-python-errors.365441/post-911195 For instance this line:
I understand that RHEL8 now defaulting to python3.6 the path conflict. I tried to enable EPEL 8 Repo in leap and it complained a gpg key was missing (ok because it is not the public RHEL key) Is their another place to indicate it ? Or say it is ok if package is removed. I have also package installed from non base rhel repo that are uninstalled in the upgrade process and adding them in to_keep didn't protected them (ideally I would want to be warned or have the possibility to specify the new name) |
Beta Was this translation helpful? Give feedback.
Answered by
pirat89
Mar 18, 2024
Replies: 1 comment 10 replies
-
|
Hi @Et7f3, there are couple of questions/issues actually, so I will try to split it and answer it. What is the use-case for /etc/leapp/transaction/* files?These files are affecting packages signed the distribution. In case of RHEL, only RHEL packages. Which means, that that removal or keep does not have any effect on EPEL packages. The reason is that we can decide what should happen only with official RPMs and we are clearly stating that we do not do anything with third-party content, which is purely in hands of users. As we needed couple of times to use these files officially to deal with some issues, we have to keep them restricted (e.g. EPEL contains some packages with same names as official RHEL packages, and based on our statement, we cannot say that such packages must be removed during the upgrade..). The exception is How the
|
Beta Was this translation helpful? Give feedback.
10 replies
-
|
Oh very smart. I am familiar with RPM but thanks for this mini tuto. I think I will use that, will report if it solves those specific conflicts. |
Beta Was this translation helpful? Give feedback.
-
|
I tried that in my VM and at least in my case it resolved the problem. But I have a different setup, so it's possible you could have problems with other packages also (not sure whether this was the only reported conflict or whether you have more on your system). Let me know how it worked. |
Beta Was this translation helpful? Give feedback.
-
The full listsI have those warning: but it should be OK because we upgrade machine to latest state available. The list I used (generated with grep/sed) |
Beta Was this translation helpful? Give feedback.
-
|
The list was not complete: I am dumb I forgot docker-compose (thus those package were required). I will retest again. |
Beta Was this translation helpful? Give feedback.
-
|
well, it's true it's suggested to use versioned obsoletes usually (for good reasons), but I guess that name of the package will be just ok in this case. I know that epel PyYaml has newer version than pyton3-pyyaml in rhel8, but as the names are different and there is not provided "python36-PyYaml" capability, it should be ok. I guess that in case of other packages it will be same. |
Beta Was this translation helpful? Give feedback.
Answer selected by
Et7f3
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi @Et7f3, there are couple of questions/issues actually, so I will try to split it and answer it.
What is the use-case for /etc/leapp/transaction/* files?
These files are affecting packages signed the distribution. In case of RHEL, only RHEL packages. Which means, that that removal or keep does not have any effect on EPEL packages. The reason is that we can decide what should happen only with official RPMs and we are clearly stating that we do not do anything with third-party content, which is purely in hands of users. As we needed couple of times to use these files officially to deal with some issues, we have to keep them restricted (e.g. EPEL contains some packages with same names as o…