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