On Wed, Nov 6, 2019, at 14:00, Karanbir Singh 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 ? > > regards A couple of points about these packages. They're used in *only* to build the distro, Red Hat has very little to do with these packages after the distro is built and shipped. Any package in this category can change/move/upgrade/downgrade/disappear/become supported however they like or not change at all. And there's not a good way for us to know what the future looks like for an individual package in this category. Some napkin math, using x86_64 as the subject arch, there are on the order of 1000 source packages that have a package or subpackage in this category. About 400 of those SRPMs are exclusive to this category (that is, there is nothing shipped in-distro). I'd be very concerned about shipping this repo enabled by default because we don't want to encourage buildtime deps on this content, and I'd really like to limit the content to things that the community actually needs from the distro which is why I wanted to maintain lists. Some of this content may make more sense to be rebuilt in a SIG or elsewhere, but there's no way to know that if we enable the firehose. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20191106/1c0014a6/attachment-0008.html>