[CentOS-devel] Reasoning behind RHEL8 packages without corresponding -devel?

On la, 19 loka 2019, Leon Fauster via CentOS-devel wrote:
>Am 19.10.19 um 16:28 schrieb Kaleb Keithley:
>>On Sat, Oct 19, 2019 at 9:27 AM Scott Dowdle 
>><dowdle at montanalinux.org <mailto:dowdle at montanalinux.org>> wrote:
>>
>>    . what has been missing here is the "reason" (some of) the devel
>>    packages aren't being released.
>>
>>
>>This question was answered earlier in this thread (by me even), so 
>>I'm a bit confused why you say the reason is missing.
>>
>>In the case of libbluray-devel, it's because Red Hat only uses a 
>>very small piece of that library, and doesn't want to have to 
>>support the whole library, including being liable for CVEs and other 
>>bugs in the parts of the library it doesn't use.
>>
>>I don't know why libXvMC-devel wasn't released originally. As they 
>>appear to have decided to go ahead and release it, apparently wasn't 
>>for the same reason as libbluray-devel.
>>
>>the src.rpm is available. Build it for yourself if Red Hat and 
>>CentOS aren't providing what you want. As a maintainer of packages 
>>in the CentOS Storage SIG, even I have to build and provide packages 
>>in the SIG that Red Hat and CentOS don't provide, e.g. 
>>userspace-rcu.. (They're in EPEL, but currently CBS doesn't/can't 
>>use EPEL.)  I don't understand why people have so much trouble with 
>>this.
>
>
>I can speak only for myself. Why this missing empathy on upstreams side?
>
>The experience forms the expectation. All major releases didn't have 
>this issue of missing devel packages. A totally missing package is a 
>different story and not comparable. I am rebuilding packages and 
>building a local repository just to have a working EL8 desktop 
>environment, so thats not the case.
>
>Its a normal expectation having canonical packages accessible. You 
>also get wet when going swimming. In the old days devel files were
>included in the main rpm. What I'm saying the main and the devel rpm
>packages belong together. The splitting is artificial and not releasing
>it is even more.
I think this analogy is incorrectly used here. *You* get wet when going
swimming but it doesn't mean that somebody else should have
responsibility to dry you off. A way you dry off is not dictated by the
way you became wet.

>As I stated already in my bug report: "If I am correct, RH's strategy 
>is to promote their platform to customers and customers being able to 
>_build_ and deliver their applications (one example is the Red Hat 
>Universal Base Image). So, its a natural expectation having the 
>corresponding devel package ..."
>
>Do not get me wrong. You guys did a great work. Despite the missing 
>statement why this (business?) decision (besides the statement you
>made for a specific package), if you do not want to support a package
>then do not release it at all ...
>
>  plainrhel8$ LANG=C rpm -ev libbluray --test
>  error: Failed dependencies:
>  libbluray.so.2()(64bit) is needed by (installed) gvfs-1.36.2-2.el8_0.1
>
>Anyway, I think we all have a notion about how the iceberg looks under 
>the water :-)
Indeed. A package might be required by another supported package but
that one would only use a limited and well-confined functionality under
the cover. A distribution vendor (in this case Red Hat) might make a
decision to limit its support to only that subset and indirectly, via a
its dependency. I wish we had a way to properly declare and provide such
technical support statement validated by build systems but we don't have
it, so a whole set of -devel packages got slashed off.

-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland