On Tue, Jan 07, 2020 at 02:06:20PM +0100, Fabio Valentini wrote: > Just to add my 2¢ here: I have experience with packaging stuff from > many language ecosystems (ruby/gems, python/pypi, go, Java/maven) and > with various build systems (autotools, meson, CMake, etc.). The > packaging burden is *vastly* different, depending on the ecosystem. > > - python / pypi works great for %build and %install, but until testing > with tox is automated in packaging macros, %check has to be specified > manually since upstream projects do different things there. > generate_buildrequires also works nicely here. > - ruby is weird, packaging gems is a bit of a chore, upstream has many > knobs to fiddle with to make distro packaging hard (for example, not > including test sources in .gem files seems to be a common practice), > there's no canonical way of running test suites, and I think the > %check section of all my rubygem packages is different and > specifically tailored to the package ... > - go and rust are pretty easily automated because there's not as many > things upstreams can mess with, %build, %install and %check are almost > always clean and easily automated with macros. generate_buildrequires > also helps with rust packaging. > - Java / maven has good support with packaging tools and macros in > fedora, but if upstream project deviates from the "standard way of > doing things", even if it is only slightly, you might end up modifying > maven XML project definitions with XPATH queries. The horror. > > For C / C++ / Vala, which don't have language-specific package managers: > > - meson is really nice, almost never manual intervention needed; but > even if it's necessary, patching meson.build files is pretty > straight-forward > - CMake is alright, even if it's hardly readable by humans; but > patching CMakeLists.txt files gets ugly > - I hope autotools dies a fiery death, and soon > > TL;DR: The packaging burden ranges from being small or near > non-existent (meson, python, go, rust) to being a chore (ruby, Java, > autotools). I don't know how nodejs packages compare, since I've been > lucky and didn't have to deal with them yet. > > Conclusion: Some things could and should be improved, but some of that > will only happen if we cooperate with upstreams (for example, right > now rubygems or Java/maven is just too wild to be tamed by any > downstream automation IMO, unless an omniscient AGI is just around the > corner and will do our packaging for us). What I read here is: there are ecosystem for which we could automate a good chunk of things. This means, if we don't degrade things for other ecosystem, we would still be improving the overall situation. Improving 20% of our work is less ideal than 90% but is still better than 0%. The advantage of this diversity is that we should be able to improve things by steps, working through each ecosystem one by one. One disadvantage that will quickly show up though will be the: if you're using X or Y languages you need to do things this way, otherwise you need to do things that way. I hear that our documentation is sometime confusing to new-comer or people who only do some packaging work every once in a while, I fear that this wouldn't help with that problem. I'm not saying that we can't or shouldn't try to improve what/where we can, just that this is something to be aware of, acknowledge and try to mitigate. Pierre _______________________________________________ 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
