Please attach a list of packages that are blocked from building. [I will update the instructions to say this.]

This prevents several packages from a third party repository from building. Some of these packages are needed to build more packages, so this ends up blocking a lot of packages.

As the (reluctant) package maintainer for libbluray in RHEL, I would advise EPEL to ship a newer version of libbluray under a different name that obsoletes the version in RHEL, for use by third-party applications that need newer versions.

gvfs itself has dropped its dependency on libluray:
https://bugzilla.redhat.com/show_bug.cgi?id=1747972
so there is nothing left in the distribution that depends on the library.

Note that the version of libbluray in RHEL7 has a different soname to the more recent versions (libbluray.so.1.2.0 in RHEL7 vs. libbluray.so.2.1.2 in more recent Fedora versions),
so you should be able to make the library packages themselves parallel-installable.

If a program were built against the newer version of libbluray, then library dependencies would automatically drag it in when that program gets installed.

If a program were built against the newer version of libbluray, then library dependencies would automatically drag it in when that program gets installed.

The problem here is, you cannot actually build against this library since the headers are missing without the -devel package.

If a program were built against the newer version of libbluray, then library dependencies would automatically drag it in when that program gets installed.

The problem here is, you cannot actually build against this library since the headers are missing without the -devel package.

I meant that you should ship a libbluray1 and libbluray1-devel package in EPEL, which would use a newer version of libbluray, with a different ABI and soname to the one in RHEL7.

Isn't that over complicating the issue?
The build should generate both libbluray and libbluray-devel packages, but only the former is being shipped. Can't we just start shipping the -devel package from the same build as the main package?

Which (shipping the -devel package) was the original request to add to CRB. While the packaging rules prohibited EPEL from replacing existing EL packages, it is not clear to me if the rules allow one to take advantage of modularity to provide alternative implementations in EPEL (so EPEL could ship a newer and complete libbluray and -devel package). If so, that might be an alternative path forward.

Following up on this as this is preventing me from providing mythtv on EL 8. Is there a definite decision on which direction to go?

While this still something that should be resolved, for MythTV in particular, for at least the most recent v31 release, the projects trac issue #13520 identified and addressed the issue.

The preferred choice for me (libbluray package maintainer in Fedora) would be for the "neutered" libbluray to be dropped from RHEL8. I think that @hadess wrote elsewhere this is due to happen for RHEL8.2, as it is not needed by gvfs anymore, but I can't find references to this right now and I may be mis-remembering. Please note libbluray is also missing the bdj sub-package, both in RHEL7 and RHEL8, but that is less of a problem than the missing -devel.
I will gladly request an epel8 branch if this happens someday.

The other choices possibly are:
- A libbluray1 package, parallel installable to libbluray as currently shipped in RHEL8 and RHEL7, with a mangled soname. But I think it will mean also patching every software that uses libbluray to choose the "good" version. And this will also require a new review and git repository to host libbluray1, so likely voids any chance to keep Fedora and EPEL spec sync'ed easily. Also, EPEL policy prevents any package to conflict with or replace an RHEL package.
- A libbluray module. Not sure if hiding an RHEL package which is not in a module with another module is allowed by EPEL policy, nor if EPEL properly supports module. I know next to nothing about module anyway, except for all the troubles they bring with them, so I'm not touching modules with a ten foot pole, that would be for someone else to do.

We finally have a solution, for this, and other missing -devel packages. Not a perfect solution, but something that is better than nothing. A wiki page is being written up, but here are the basics.
CentOS has a new "Devel" repo, that contains some/many of the missing -devel packages.[1] We have tested and found that EPEL8 packages will build utilizing that repo. We have setup EPEL8 so that it uses that repo, and packages can now be built that need the packages in it.

Problem1: There is no s390x builds.
Workaround1: In your EPEL8 rpm specs you will have to use ExclusiveArch, or %ifarch, or something so that your builds do not build on s390x, or skip that library for s390x.

Problem2: Not all missing -devel packages are in the repo.
Solution2: You need to open a CentOS issue that states what devel package is missing (in this case libbluray-devel) and packages it is affecting (in this case mythtv, possibly more). You then have to get this ticket "related to" issue 0016492.[2] Then it's a waiting game.
Reason2: The CentOS community is utilizing their bugs to show Red Hat why certain -devel packages are needed. Will they be more successful than our EPEL issues? I don't know. But that is why they are not simply adding all missing -devel packages.

[1] - http://mirror.centos.org/centos/8/Devel/
[2] - https://bugs.centos.org/view.php?id=16492

@tdawson that is great news, thank you for making that possible.

Is there any plan for the other missing sub-packages ?

in the libbluray case, there is libbluray-bdj which is built but not published anywhere.

Another example could be all languages binding for lasso, which are also built, but not published. For this one, I'd be interested in perl-lasso, needed by lemonldap-ng, which I hope to bring in Fedora/EPEL someday.

But I'm getting off-topic for this issue...

Again, thank you , every step in the right direction is appreciated.

Not a perfect solution

Understood, but thank you, and the CentOS team, for taking on this necessary step.

The preferred choice for me (libbluray package maintainer in Fedora) would be for the "neutered" libbluray to be dropped from RHEL8. I think that @hadess wrote elsewhere this is due to happen for RHEL8.2, as it is not needed by gvfs anymore, but I can't find references to this right now and I may be mis-remembering.

I'm afraid that there isn't a process for retiring and removing a library in the middle of a release. It's utterly frustrating that I was never actively asked whether this library should be in RHEL, or whether this library should be in RHEL without the -devel package.

@hadess, libbluray is in AppStream, which I understand to not be as stable as BaseOS is, so maybe there is hope ?

At least libssh2 has been dropped between 8.0 and 8.1, so this seems possible. And libssh2 is now happily living its life in EPEL 8, -devel package included.

As both you as the RHEL maintainer and me as the Fedora maintainer are in favor of dropping this package from RHEL8, maybe there is a slight change for this to happen ? Would you have any way to push that up to the people in charge ?

FYI, per the new process, I've opened a bug with CentOS which has created a devel only repo. This is a patch not a fix though.

https://bugs.centos.org/view.php?id=17214

@hadess, libbluray is in AppStream, which I understand to not be as stable as BaseOS is, so maybe there is hope ?
At least libssh2 has been dropped between 8.0 and 8.1, so this seems possible. And libssh2 is now happily living its life in EPEL 8, -devel package included.
As both you as the RHEL maintainer and me as the Fedora maintainer are in favor of dropping this package from RHEL8, maybe there is a slight change for this to happen ? Would you have any way to push that up to the people in charge ?

I've already done that, and there isn't that I could find.

I would personally go with hadess proposal to have libbluray1 in epel8 (and withdraw the -devel request in CentOS). So we can have a single "pkgconfig(libbluray)" provider for EL8 and go with a fully enabled, not outdated version.

I don't believe the libbluray1 option will work. libbluray in RHEL8 has the file libbluray.so.2, same as what is shipped in the latest version of libbluray in Fedora. The only way to make that parallel installable would be to mangle the soname, which is not easy and not recommended.

There are two possible solutions to this problem that are documented in our FAQ.

• Add a libbluray-epel package to EPEL, based on the RHEL spec file, but only providing the missing libbluray-devel subpackage. No resulting package names or files can conflict with what is shipped in RHEL.
• Ask RHEL to ship libbluray-devel.

Based on @hadess's responses here, I suspect the answer to the latter will be no. Alternatively, if RHEL8 formally deprecates libbluray, the EPEL Steering Committee will consider granting an exception to policy to allow the complete libbluray to be shipped in EPEL8 with a higher version than what is in RHEL8. This is probably the best solution IMO.

I'm going to close this out as EPEL can't change the content in CRB ourselves, and the possible solutions don't require a top level EPEL issue. Although if libbluray does get deprecated in RHEL8, we can reopen and repurpose this issue for the Steering Committee to decide on a policy exception for allowing libbluray in EPEL8.