On 07/01/2020 10:57, Zbigniew Jędrzejewski-Szmek wrote:
It is pretty clear that we've simplified rpm packaging massively over the last few years. It is enough to take a random spec file from 10 years ago, with all the fragile manual steps and compare it with modern spec file that is often just a bit of boilerplate to provide the name, version, license and description, and then call some macros that do all the heavy lifting. We've made great strides in making to bring rpm and upstream packaging closer. And this has been an effort on both sides, both upstream to accommodate workflows required by distros, and on the distro side to wrap those workflows: automatically generated spec for rust packages, pyproject macros, etc, etc. Also spdx licenses, automatic github tarballs… But it is clear that this automatization process is far from complete. And to stay relevant, we (and other distros) need to keep up this work. Without that, we'll never keep up with the infinite supply of upstream projects and we'll stop being useful to users.
The thing is that no matter how much you can manage to automate the creation of spec files for a given ecosystem, and I've never seen one where the typical spec file doesn't need some manual tweaking, you are still going to hit the fundamental problem that those specs then need to be reviewed. In the typical "modern" ecosystem where everything is split into hundreds of every tinier components review bandwidth is the single biggest limitation and unless you're going to abandon reviews as part of automating distribution of upstream components I just don't see how this can work. I'd love to find a way to directly integrate the likes of gem, npm etc directly into our packaging rather than us having to repackage everything by hand but I just don't see any way of doing it without compromising what we do to the extent that we're not really doing anything useful at all and are just shoveling out whatever nonsense upstreams perpetrate without question. Tom -- Tom Hughes (tom@xxxxxxxxxx) http://compton.nu/ _______________________________________________ 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
