Am 06.11.19 um 21:00 schrieb Karanbir Singh: > 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 ? I think the repo name should be clearly communicate what it is, "addons" seems for me misleading. Its not only about -devel packages, for examples avahi-dnsconfd is build but unshipped. Therefore the name should communicate something like "build but not shipped and therefore unsupported". -- Leon