On Wed, Nov 6, 2019, at 8:01 PM, Stephen John Smoogen wrote:
On Wed, 6 Nov 2019 at 15:01, Karanbir Singh kbsingh@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.]