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