[CentOS-devel] Unshipped -devel packages in CentOS Linux

[Nico Kadel-Garcia]

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.