Open ncoghlan opened 9 years ago
strzibny
commented
9 years ago 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
commented
9 years ago 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
commented
9 years ago 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
commented
9 years ago 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
commented
9 years ago 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
commented
9 years ago 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
commented
9 years ago 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
commented
8 years ago 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):
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
commented
8 years ago 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
commented
6 years ago @encukou, @hroncok, @kasicka, @msehnout, WDYT?
The new RPM Packaging guide is great, but in many cases folks can generate a decent starting SPEC file from upstream metadata, rather than having to start from scratch. Two tools I'm aware on that front:
I assume similar tools exist for at least some other language ecosystems, I'm just not aware of them personally.
In terms of structuring this, the layout that makes sense to me would be to have:
If that layout seems reasonable, I'd be happy to put together a PR using Python and pyp2rpm as the initial example.