On Wed, Nov 6, 2019 at 12:37 PM Brian Stinson <brian at bstinson.com> wrote: > > > Hi Folks, > > We're gearing up to build the next minor release of CentOS Linux 8 so I thought > now would be a good time to revisit the conversation we've been having about > what to do with unshipped -devel packages. Just a reminder on a few guiding > principles: > > - The BaseOS, AppStream, and PowerTools repos in CentOS Linux are designed and > composed to match Upstream as closely as possible, both in content and behavior > > - Unshipped devel packages have no defined maintenance lifecycle in Upstream, > and especially not in CentOS Based on the source for "quota", these "devel" packages are built along with the binary RPMs. It takes extra work to exclude them from publication along with the binary RPMs. If Red Hat is publishing the SRPM, and building the RPMs, it is capricious to exclude the "devel" packages. As best I've seen over more than 20 years, they have never pulled this stunt before. > - We know that some of these devel packages are essential to build applications > that the CentOS (and probably EPEL) communities care about. > > > The problems we need to solve if we decide to ship these packages somewhere in > a CentOS artifact: > > - Communicate that these packages are provided as-is and are not meant for > runtime dependencies > > - Provide the packages in a form that is consumable for individuals and the > EPEL community Well, yes. A polite note that Red Hat elected to be really silly about this one should serve quite well. > I'd like to propose that we create a separate repository, disabled by default > that is composed of the -devel packages that we care about, bundled in a module. > > The name of this repository and the module is up for discussion, but I would > like the naming to help with the communication that these are not for general > consumption. Please don't. The current multiplicity of streams from upstream is, in my observation. pretty foolish. There is no separate stream to put the SRPM ijn, because the published SRPM bullds the quota-devel package. (I checked as part of resolving the quota-devel dependency for Samba with the full domain controller enabled for RHEL 8). The software license for the quota package is GPLv2, there is no problem publishing the devel package. > I'd also like to discuss how we populate this repo/module. It would be Just leave it in the mainliine repos. In this very small way they will differ from RHEL. But this is, I think, the only case I have ever seen RHEL refuse to publish the accompanying devel package with a binary package. It's not behavior to emulate. > easiest to just dump every unshipped package in and move on, but that This is *not* an unshipped package. This is a package that is shipped, it's necessary for compiling Samba with domain-controller enabled, it's included in the upstream Fedora builds, it's compiled automatically along with the binary package, and it was deliberately excluced. > doesn't help us track which of these packages are truly important > outside of building the distro. Shipping *everything* also represents a > larger content set to manage if lifecycle issues come up in the future. > An alternative would be to store this definition in git (we'll need to > do that anyways), and allow folks to make pull requests to include new > content, shipping this as a separate repo would let us spin updates on > demand. Well, yes. If you'r4e going to include development libraries at all, it's going to be a larger set of repositories. But picking and choosing which to ship binaries, and which to exclude include files for this way is new behavior and quite capricious. It makes me quesiton what the motive is. And as much as I hate to think it, I think it's to hinder Samba domain controller deploymen in favor of FreeIPA, which seems to have become a sore point. And no. There is no need, nor exuse, for module wrapping something that is a critical system component. Fedora is in the midst of some very heated discussions about the benefits, and lack of benefits, of modules, and interjecting them into this kind of already built, the SRPM already builds the devel package, discussion is distracting clutter.