Mentioning language specific tools in the RPM Packaging guide

[developer-portal]

Mentioning language specific tools in the RPM Packaging guide

[strzibny]

I would actually prefer just links from this guide to relevant guidelines/info we have already in Fedora wiki - which is the place for developers that develop Fedora (as opposed the goal of developers that just develop on Fedora).

[strzibny]

To be more precise:

An RPM Packaging section in the relevant language page that describes how to use the SPEC file generator, and then links to the main RPM Packaging guide

Let's not do this. Let's keep the info on packaging just in the RPM packaging section. There are already links to Special Interest Groups and I think that's enough.

A summary section in the main RPM Packaging guide that lists the languages with SPEC file generators and links to the appropriate section on the language page

Instead of to the appropriate section on the language page I would say to the appropriate Fedora wiki pages. Fedora Developer Portal is not here to replace the wiki. Perhaps in far future we can try to do in, but let's avoid that now.

[ncoghlan]

The wiki is not a suitable resource for folks packaging on Fedora.

When we're making packages for Fedora, they need to meet much stricter policy requirements than if we just want to do things like bundle up an entire Python virtualenv for deployment as an RPM, or do an initial conversion of an existing upstream project to SRPM to upload it into COPR.

It's the latter kind of policy non-compliant instructions I'd like to see in the Developer Portal, as a way for folks to get started with making use of RPMs before they get into the complexities of distro policy compliance (and having to come to grips with the long term maintainability perspective driving the design of those policies).

[strzibny]

Ok, I admit that it's not that nicely documented on the wiki. We have a mention of Ruby SIG in the content and on Ruby SIG wiki page we mention gem2rpm, but there is no HOW TO.

The thing why I don't like the idea of including in tech/languages section is that before talking about gem2rpm you need to explain a lot about packaging itself...I would probably like it more in packaging/Copr sections....

[ncoghlan]

I don't think it's necessarily true that you need to know a lot about packaging to use tools like gem2rpm, pyp2rpm or cpanspec successfully - those tools encode a lot of knowledge in their templates, so you can get started using them mechanically, and then use what they generate as a road map for understanding RPM concepts.

Or, alternatively, if distro policy compliance isn't a goal, or if the upstream metadata design has been refined to a point where policy compliant packages can be generated automatically in most circumstances (which is what we're aiming for upstream in the Python Packaging Authority), they can substitute for learning about RPM based packaging entirely.

Probably the best way forward here is for me to come up with an example PR for Python that shows what I'm proposing as a general structure, as well as pointing directly to the upstream docs for cpanspec, gem2rpm and the rpm-maven plugin. I'll aim to get that done within the next week.

[strzibny]

Btw we also aim for automation in gem2rpm, but it's not entirely possible (C extensions are a bit problematic). You still need RPM knowledge to finish it. On the contrary there are tools on the internet when this knowledge is not needed as they avoid writing SPEC files at all. Not sure we want to encourage these.

[ncoghlan]

For the "no SRPM" case, I like the approach of bundling up an entire language level virtual environment (binaries, metadata files, and all) and deploying that. That's the way the rpm-maven plugin works, and I see it as fairly comparable to do the same thing as a Docker image layer, just with a different deployment technology.

[marbu]

As a newcomer to Fedora packaging, I feel that this is a valid point: fedora wikipages of language/platform guidelines provide way too much detail and doesn't always follow the same structure (different approach works for each group) - which is completely fine as far as the group is concerned.

But here our message to get through is more general: for many languages such as python, perl, ruby, haskell (and others):

• it's not a good idea to start writing a specfile from a scratch
• one can use some automated tool (pyp2rpm, cabal-rpm, ...) to create an initial specfile from an upstream metadata format (assuming that the project follows upstream guidelines)
• one still needs to have a basic knowledge of rpm and fedora guidelines of particular language to tweak it and fix issues

But it's a great help. For example I was able to package taffybar (taskbar implemented in haskell) using cabal-rpm tool and 8 packages (not yet packaged deps) didn't require any additional editing at all, taffybar itself was a bit harder, but only because I cared too much about the quidelines.

Also see I how I imagine ideal python packaging workflow, it would make sense to write down something like this, but for all languages for whitch this kind of workflow is available, link to the tools and last but not least a link to the fedorawiki guidelines as an ultimate source of information.

I could provide some examples for python and haskell if needed.

[phracek]

I would be glad to separate it for all available languages.
Could you please send us a PR?

Or even some template would be welcome.
I can only say, we need both approaches. As from the scratch as from template or similar.

[pvalena]

@encukou, @hroncok, @kasicka, @msehnout, WDYT?