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! 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? 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 ... -- Leon