Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> writes: > On Wed, Nov 18, 2020 at 03:37:11PM -0500, Alexander Scheel wrote: >> I second what Robbie has said as well. >> >> I am against the thought of this change. >> >> As my team has found out within Red Hat, this repo split has been a >> large PITA. Because RHEL also won't self-host and many sub-packages >> are missing from released bits that are otherwise available in e.g., >> BUILDROOT, building our bits in COPR for QE to test has been an >> impossible battle. After close to a year, this use case still hasn't >> been enabled internally. > > But that's not what's being proposed. Isn't it? Some packages go in main, and others go in light (or whatever it'd be called)? > We've had different repos in Fedora for years -- the main repo, plus > updates, plus updates-testing. And we have the separate modularity one > now. Fedora is going to continue to self-host, and doesn't have > whatever business reason RHEL has for not shipping the buildroot. I think that conflates uses of the word "different". The package sets between main/updates/updates-testing are not meaningfully different: almost all packages in updates/updates-testing already have a version in main. That is, you would have a complete system with pretty much every package available just by setting up main. That's of course not how RHEL-style repo separation works: packages in AppStream, for instance, or BuildRoot, are wholly disjoint from those in BaseOS. (This is also how generalized modules behave.) 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. Thanks, --Robbie
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 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
