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

[Alexander Bokovoy]

On su, 20 loka 2019, Leon Fauster via CentOS-devel wrote:
>Am 20.10.19 um 12:42 schrieb Alexander Bokovoy:
>>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.
>>
>
>What about custom software builds that use exactly only this supported 
>part of the library? It can not be build because of the missing header 
>files!
Like I said above already, we don't have a way to properly declare and
provide such fine-tuned technical support statement validated by a
build system. A granularity is what it is, a whole -devel package.

>Take a look at the openssl package; if it is not supported, its 
>cleaned out (hobble version) and the full output of the build process 
>are provided (all packages).
>
>Actually we based this discussion on the explanation for the case of 
>libbluray-devel but what about the others packages?
We can argue for every package but at the end, there are teams that own
maintenance of the packages. They make the decisions and those decisions
then get through product management. Sometimes they get cut in the
middle, sometimes they already put down by the teams themselves.

>Examples are (incomplete list):
>* avahi-glib-devel
>* avahi-gobject-devel
>* avahi-tools
>* avahi-ui
>* avahi-ui-devel
>* gfbgraph-devel
>* liba52-devel
>* libdmapsharing-devel
>* libdvdnav-devel
>* libuv-devel
>* libXvMC-devel
>* qgpgme-devel
>* rest-devel
>* totem-pl-parser-devel
>
>A distribution vendor have of course the right to limit the support
>but this specific case (missing devel rpm) leaves a bad taste on 
>customers side and results in a bad experience. IMHO this experience
>contradicts RH's strategy pushing this platform ...
I think a productive way would be to file bugs asking to get the
packages in, with explanation why they are needed and how they would be
used.

I did the same for quota-devel already -- its lack doesn't allow us to
test the quota-related functionality in Samba CI upstream, for example.

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