El 6/11/19 a las 17:18, Karanbir Singh escribió:
On 06/11/2019 20:14, Leon Fauster via CentOS-devel wrote:
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".
to me, addons communicates just that, and has existed in the past - also, nothing in CentOS is 'supported'.
Right, but normally things in CentOS are supported in RHEL, these packages don't fall into that category.