Request that conversion script first check for extra repos enabled

[Ussat]

Request that conversion script first check for extra repos enabled, and flag them in an output/warning before attempt to run, for example if the user has remi's repo enabled etc. Also, possible verify ability to connect to oracles's repo is avaliable.

[Djelibeybi]

Those are both great suggestions.

[Ussat]

OK, I also notice that if a system (in this case Centos 7) has epel installed, it is replaced with oracle-epel-ol7.repo.

While all the old Centos repos are appended with ".disabled" see examples below:

-rw-r--r-- 1 root root 1836 Feb 20 15:35 CentOS-Base.repo.disabled -rw-r--r-- 1 root root 1481 Feb 20 15:35 CentOS-CR.repo.disabled -rw-r--r-- 1 root root 821 Feb 20 15:35 CentOS-Debuginfo.repo.disabled -rw-r--r-- 1 root root 486 Feb 20 15:35 CentOS-fasttrack.repo.disabled -rw-r--r-- 1 root root 802 Feb 20 15:35 CentOS-Media.repo.disabled -rw-r--r-- 1 root root 1503 Feb 20 15:35 CentOS-Sources.repo.disabled -rw-r--r-- 1 root root 8687 Feb 20 15:35 CentOS-Vault.repo.disabled -rw-r--r-- 1 root root 788 Feb 20 15:35 CentOS-x86_64-kernel.repo.disabled

it would be just as easy to append epel.repo with epel.repo.disabled and not remove it.

I understand the reasoning, ( I think ) keep everything oracle, but the oracle epel is several versions behind on various pieces of software. One could simply rename epel.repo ( as stated above ) instead ov removing it, OR, better yet, offer the admin a choice. Would be even BETTER if that choice were a flag passed to the script.

Just some thoughts.

While I am on a roll,

Is there any reason for having both after the script is done:

-rw-r--r-- 1 root root 32 Sep 30 12:49 oracle-release -rw-r--r-- 1 root root 52 Sep 30 12:49 redhat-release

Cheers

[Djelibeybi]

We're aware that our EPEL is behind: it's because we're focused on bringing our EPEL8 mirror to parity with upstream and there are a finite number of EPEL packages we can support in QA and release at once. So updates to EPEL7 are done inbetween package releases of EPEL8.

Having a parameter that allows the user to chose whether to switch from upstream EPEL to Oracle EPEL would be a great feature.

And the reason we have both release files is because a lot of software installers only check for one of them and I'll let you guess which one. We retain the upstream version so that installers still work on Oracle Linux.

[Djelibeybi]

Also @mark-au created a nifty mapping function that allows us to map repos from upstream to Oracle. The Remi repo could be mapped to our PHP developer repos, for example. I'm not sold on this because unlke EPEL, we're not trying to maintain parity. I'd prefer to only map repos that are designed to be 1:1.

[Ussat]

I agree in mapping 1:1 is the best option. Regarding choosing between EPEL and Oracle's EPEL, I think a great interim step would not be to delete the epel.repo but just rename it with .disabled, and not remove it, and then just print out at the end of the conversion, "The following repo, epel.repo, has been renamed to epel.repo.disabled. " I just think removing it totally is a bad call.

That way, users would not be left wondering.

[Djelibeybi]

I think that's reasonable. :) Pull requests welcome from folks who've signed the Oracle Contributor Agreement.

[Ussat]

OK, guess I should read that and start some updates eh ?

[Ussat]

OK, not sure this the place to carry on this convo, but I assume I will be told if it isn't. I am a bit leery to fill out the OCA, because it seems I need an Oracle account, and when I went to get one it asked me all sorts things about where I work etc, work email, work phone, company name etc. I am uncomfortable about this for a few reasons, 1)Why does Oracle need to know this when all I want to do is help a project ? 2) I am not sure where I work would be cool with me giving out that info for this reason. I mean, come on, I am just wanting to help out but your not making it easy.

[Djelibeybi]

Understandable. We generally require the same sort of information as most organisations with a contributor license agreement do, including the Linux Foundation and others. The OCA FAQ should answer some of your questions and depending on where you work, your employer may already have a signed Corporate CLA so you could also check internally if that's the case.

The FAQ also includes a "Discussing the OCA" section which explains what methods are available for negotiating the CLA as well as commenting on or asking questions about it.

[delatbabel]

One artifact of removing the EPEL repositories is that the remi-release package requires the epel-release package and repositories, and there are packages in REMI that require other packages in EPEL. So I was a bit surprised when I started to run this script and saw that it just summarily removed my remi-release package and all of the installed REMI packages. Fortunately I was just running this on a test server so I could simply rebuild it.

Why not just copy the epel-release and remi-release packages into the Oracle repositories? As a developer, the REMI packages are absolutely fundamental.

[Djelibeybi]

We can't distribute packages we don't build ourselves and we haven't built the REMI packages.What we really should do is provide an option for folks to not switch out the non-core repos.

[delatbabel]

It's not necessary for you to build or distribute the REMI packages, or the EPEL packages either. As per the REMI instructions, everyone normally grabs the necessary RPM from https://rpms.remirepo.net/enterprise/remi-release-8.rpm -- it's only distributed by REMI. However that RPM does rely on the epel-release RPM which is found in the CentOS repositories. CentOS doesn't carry the EPEL packages, just the epel-release RPM which contains the necessary yum.repos.d files for EPEL. All that you would need to do is to put an epel-release package into your repository that also contains the yum.repos.d files -- doesn't have to be the exact same epel-release package that CentOS carries, it just needs to be any package named epel-release so that the dependency of remi-release can be met. Of course it should also carry the necessary yum.repos.d files for EPEL, if you wanted those to point to your own build of EPEL then they could, otherwise they could point to EPEL from the Fedora mirrors as they do at the moment.

The remi-release package doesn't care which epel-release package fulfils its dependency requirements, it just has to be any package named epel-release.

Of course having centos2ol not remove my existing epel-release package would also partially solve the problem. Actually I don't use very much from epel but I do need things from remi and if it's going to remove epel-release then it also removes remi-release and that causes all of the REMI packages to be removed and I can't allow that.

However it's still only a partial solution. What I'd like to do is to install CentOS (because the Oracle installer is slightly broken for my installation use case but that's a completely different issue in a completely different bug tracker), upgrade my newly installed CentOS to Oracle, then continue with my regular installation script which installs EPEL then REMI and then other stuff and so on. If you don't have your own epel-release package then I can't install EPEL or REMI after centos2ol, I have to install them before, and that's an extra step. Furthermore, if they fix the Oracle installer and I then do the Oracle install, I can't install epel-release and then remi-release if you don't have an epel-release package for me to install.

[Djelibeybi]

Modifying oracle-epel-release-el7 and oracle-epel-release-el8 to Provide: epel-release should work. I'll log an internal ER for this.

[delatbabel]

100% yes that should work.

[Djelibeybi]

Internal ER logged.

[totalamateurhour]

Modifying oracle-epel-release-el7 and oracle-epel-release-el8 to Provide: epel-release should work. I'll log an internal ER for this.

This was implemented as of oracle-epel-release-el8 1.0-4.el8

[carlwgeorge]

It's disappointing that it was decided to add an incorrect provides rather than rename the Oracle repository. Calling it EPEL when it doesn't provide all the packages that EPEL does is confusing for users and hurts the reputation of both EPEL and Oracle. When I looked at this back in November, there were 423 (86 EPEL7 and 337 EPEL8) packages missing from the Oracle repos. The problem has gotten worse since then; there are currently 679 (393 EPEL7 and 286 EPEL8) packages missing from the Oracle repos. This doesn't even count the complete absence of an Oracle repo tracking EPEL9 (an additional 4585 packages). I suspect that if this continues to be a problem, third party repos like remirepo (CC @remicollet) may just add Conflicts: oracle-epel-release-el<version> to their release packages to get users to install the real epel-release package.

On a related note, there are a significant number of packages in the Oracle repos (602 EL7 and 592 EL8) that are not in the corresponding EPEL repositories. I would like to see Oracle collaborate with EPEL maintainers to make these packages available in the real EPEL repositories. We even have a guide for engaging with EPEL maintainers on package requests.

Please consider removing Provide: epel-release and renaming the Oracle repo to something else besides EPEL.

[Djelibeybi]

My understanding is that were were only going to add epel-release once our EPEL repos matched (within a few days) the upstream repo. @totalamateurhour if this is not the case, I agree we should remove epel-release until we achieve this status.

Renaming the repo was something I also suggested internally but was rejected. I think this should also be reconsidered.