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




[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