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. Zbyszek _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
