On Wed, Nov 6, 2019, at 20:31, James Cassell 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? > > > 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? > > > V/r, > 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.] > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > https://lists.centos.org/mailman/listinfo/centos-devel Anything we do needs to be an output from the build/compose tooling that we use to produce the distro. We're trying to keep the repodata hacking to a minimum.