On Thu, Nov 19, 2020 at 03:04:26PM -0500, Robbie Harwood wrote: > What I believe Alex and I are arguing is that there is no technical > advantage to RHEL-style repo-splitting where some packages go in one > repo and a non-overlapping set goes in another. Rather, it incurs a > large burden both on maintainers and end-users. Remember, I'm trying to solve a real problem here: Some packagers in Fedora do not have time to maintain the build dependencies for the packages that they are actually interested in and have time to build. The RHEL solution is to not ship those. The packagers don't feel good about just dumping the — as we've said, "lightly maintained" — deps into the package collection. They'd feel better _not packaging the main packages in Fedora at all_. This is not a good outcome. I'd like to find a better approach, and having a repo for these things (which, as I've said, unlike RHEL, we'd absolutely ship) is one idea that came to mind. However, I'm not stuck on that one and it's probably not useful to stay stuck on it if there's not enough support to do it. So, let's find a different solution. One approach suggested was a tag in spec files themselves. Another one might be to have metadata in a separate file in dist-git. Another would be to have an external service which maintains the list — like PDC does for "critical path" packages. Such a system could also be used for other things, like defining a minimal core which we'd want to apply greater CI gating and scrutiny to. (Maybe the existing critical path set is a good start, but I'm thinking something that starts smaller.) -- Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> Fedora Project Leader _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
