On Tue, Jan 7, 2020 at 1:31 PM Tom Hughes <tom@xxxxxxxxxx> wrote: > > On 07/01/2020 12:22, Miroslav Suchý wrote: > > Dne 07. 01. 20 v 12:41 Tom Hughes napsal(a): > >> The thing is that no matter how much you can manage to automate the > >> creation of spec files for a given ecosystem, and I've never seen one > >> where the typical spec file doesn't need some manual tweaking, you > >> are still going to hit the fundamental problem that those specs then > >> need to be reviewed. > > > > I disagree. > > Especially with libraries - be it python, gems... it can be very well automated without the need for review. > > Well that depends on the reason for the review, doesn't it? > > Just to take a few things, how does automation check that the license > declared in the upstream metadata is correct? or that the upstream > package is obeying FHS and not installing files in the wrong place? (snip) > I have extensive experience with npm and packaging Node.js libraries > in Fedora and even a well behaved upstream is rarely fully automatable > and many upstreams are not well behaved. > > Tom 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). Idea: What would be nice to see from more tools would provide introspection or machine-readable output from stuff run in %build and/or %install. For example, maven/XMvn automatically generates file lists. I think automating things in %files should be doable for more ecosystems (python? ruby?). PS: I *do* think packagers add value by packaging upstream projects *correctly*, basically by providing a unified abstraction over all the weird things that upstream projects can do, and sometimes actually do. It makes it easier for consumers, because they know what to expect when they "dnf install rubygem-foo", whereas "gem install foo" or "pip install foo" might run and do all sorts of weird shit you don't want. Fabio > -- > Tom Hughes (tom@xxxxxxxxxx) > http://compton.nu/ > _______________________________________________ > 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 _______________________________________________ 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
