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

On Wed, 6 Nov 2019 at 21:31, James Cassell <fedoraproject at cyberpear.com> wrote:
>
>
> 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?
>

It depends on what the build tools allow for. A lot of this is machine
code built which means a scrape tends to need a lot of hand holding to
keep up with X.1947012340 is now X.1948012441 after an update because
both will be there in the repo (I think this is because some software
needs to have all the variants in between for updates but I am
probably confusing it with something else)


> > 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.
>

If someone wants to write the tools to do that.. I think we would all
appreciate it.


> > 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?
>
>

When I was playing with this in the RHEL-8 Beta it was due to how
modules 'filter' what they will allow to be installed. Various modules
had filters which would block various packages, and the only way to
get them installed was to switch to an alternate module which had
those items in it. You have to do alternate modules for this because
for like the perl which ships 5.24 and 5.26.. the package names are
the same and some of the -devel from those will only work with the
5.24 or 5.26. [Same if they ship alternate ruby/python38/rust/etc]


-- 
Stephen J Smoogen.