Re: Let's talk about Fedora in the '20s!

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux