On Tue, Jan 07, 2020 at 02:28:46PM +0000, Zbigniew Jędrzejewski-Szmek wrote: > On Tue, Jan 07, 2020 at 03:18:16PM +0100, Pierre-Yves Chibon wrote: > > 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. > > I agree with pretty much everything you're saying, except for one thing: > documentation *will* help. After all, we've always had language-specific > packaging guidelines, nothing new here. Packaging of different ecosystems > is inherently different. Sorry, I think my wording was confusing, in "I fear that this wouldn't help", "this" was not meant to refer to the documentation but more to the idea of working/improving/automating some ecosystems separately from the others. I agree with you that documentation is essential, to be honest it is even the only thing I can think of at the moment that will help mitigating differences in workflow as we make changes. 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
