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

James Cassell

fedoraproject at cyberpear.com
Thu Nov 7 02:31:05 UTC 2019

On Wed, Nov 6, 2019, at 8:01 PM, Stephen John Smoogen wrote:
> On Wed, 6 Nov 2019 at 15:01, Karanbir Singh <kbsingh at centos.org> wrote:
> >
> > On 06/11/2019 18:44, Pablo Sebastián Greco wrote:
> > >
> > > El 6/11/19 a las 14:35, Brian Stinson escribió:
> > >> I'd also like to discuss how we populate this repo/module. It would be
> > >> easiest to just dump every unshipped package in and move on, but that
> > >> 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.
> > >
> > > I would love to see *Everything*, but it could be problematic with
> > > modules like python36 (blacklisting all the python2 rpms) and python27
> > > (blacklisting all the python3 rpms)
> > >
> >
> > we've got precidence here in the addons repo that was shipped in past
> > versions, where content built but not shipped clearly upstream was
> > avaialble.
> >
> > at the very least, content coming from srpms that have a corrosponding
> > binary in the other 3 repos should ship by default.
> >
> > how much content are we talking about that comes from srpms that dont
> > have a single component that ships in the main 3 repos ?
> >
> > Also, i would leave this repo enabled. there isnt anything conflicting
> > with the distro rpms here is there ?
> >
> Actually there will be. Because a module blacklists things and does
> not want those unshipped items installed while it is installed. You
> thus have to create a full module which contains all the previous
> content and the previously blacklisted content.

Can't you just scrape the built but not shipped artifacts from the build system, and synthesize the repo/module data? Does it actually have to be a separately built module?

> So let us say the python27 module ships python27-foo but does not ship
> python27-foo-devel. You need to create a new module with all of
> python27, python27-foo so you can have python27-foo-devel. [This is
> because the Name-EpochVersionRelease between the python27-foo and
> python27-foo-devel need to match to install.. and modular builds get
> unique names.

Seems like this constraint would be satisfied with synthesizing module data.

> You can't have a seperate module with just python27-foo-devel in it
> because the first module has a filter which will 'conflict' at the
> modular level. This means this addon repo will have to have a
> 'conflicting' python27.

Is this because of the NEVR constraint or something else?

James Cassell

> [Because any update within a module means a complete new module build,
> you are either going to respin this BatteriesNotIncluded repo for
> every update, or just updating say a Python27 or a Python36 or a
> FreeIPA etc submodule.]

More information about the CentOS-devel mailing list