rpm build?

[bgstack15]

I realize the rpm users are supposed to use the rpmfusion repo, but I hope to be able to submit a PR eventually with Fedora rpmbuild support in this repo. If you are certain you will not want it at all, please close this issue.

[K0-RR]

I too would prefer an official build rather than having to trust another persona. Why not just use the Open Build Service? The reference public instance by openSUSE at https://build.opensuse.org/ allows building packages for multiple distros like Debian, Ubuntu, Fedora, openSUSE at once.

[ferferga]

Every extra package we support is additional burden we need to handle (and we tried in the past). It's impossible to support everything.

Why not use the portable version or Docker?

[joshuaboniface]

@ferferga pretty much hits the nail on the head.

For some context: As the main package maintainer, I have very little familiarity with RPMs. I do not use RPM-based distros personally or professionally. I've tried to hack my way through it over the years, with some occasional help from other people in the community, but it has always been flaky and a constant source of problems and frustrations at release time ("our Fedora builds are failing" was so common we disabled them for a long time), and this came to a head while trying to craft a unified packaging configuration in this repo (like we did for Debian packages). I could not figure it out. I then found the RPMFusion instance and it not only already did what I wanted, but was being actively maintained and updated by actual Fedora/etc. users.

A further benefit of RPMFusion is that they actually provide a YUM/DNF repository, which we cannot do without running an RPM-based server (which, we don't) because no tool similar to reprepro exists on Debian for managing RPM repos cleanly. So at best, we can only provide raw .rpm files for download, which is suboptimal.

This support status matches the package status for other distros too, like Arch, Gentoo, and NixOS. All of them are maintained by members of their own communities so we don't have to. This change simply moves RPM into that category as well.

As for "official" vs not - the only difference is who triggers the builds. It's going to pull the same source code from the same repositories as this one does, so I'm not sure there's a huge difference there, especially when we get into automated services.

Regarding OBS, we don't use it and are not really interested in it. I reviewed it extensively back in the day and found it easier to manage if we just handled our own builds, and I don't like having such a service only for one type but not the others.

Ultimately what I'm getting at is, I'm not interested in doing the work, and after 5+ years no one else really has been either. If someone is able to provide a complete implementation here that (a) builds the RPM binary packages from source using a single spec, within a Docker container, using the build.py script (i.e. how Debian packages work), and (b) uploads them to an actual RPM repo somewhere; or, provides us a tool (new or already existing) like reprepro so we can create a YUM/DNF repo under a Debian server webroot, and we can restore "official" RPM support. Until those two things happen, we're going to recommend RPMFusion or Docker.

[bgstack15]

While I hope to provide a full ability to produce those individual rpms which are not ideal, a byproduct of this process is the src.rpm which can then be used by anyone (such as myself) to build in OBS or copr (the Fedora community repository project). I'm guessing the npm and dotnet versions will make CentOS 7 packages unfeasible, but I'll work on modern Fedora/Enterprise Linux versions before trying to get crusty old CentOS 7 going. I'm starting with adapting the 10.8 package from rpmfusion but have to learn some dotnet/nuget and npm package management first, so the rpmbuild process itself does not need network access.At the time of this writing, the 10.9.0 rpmfusion packages were not found.

[joshuaboniface]

To be honest, if all our process would do is generate a source RPM, and then upload it to another service to build again... why not just use that other service from the beginning? And it's not just about the initial implementation, but the continuous ongoing maintenance as Jellyfin changes. These are the main reasons we dropped support. I work with .debs and Docker containers daily; I almost never except within this project work with .rpms, and keeping them working over time was the real burden.

I stand by what I said regarding accepting a complete spec and build process, but I also want to stress that if 10.10 comes and it's not working, I will not maintain it, and it will be dropped again. This is why we want to offload to RPMFusion or somewhere else, so that a group of people actually knowledgeable about RPM packaging can handle it instead. Hopefully that clarifies my stance a bit more.

[bgstack15]

This seemed like a centralized place to provide an rpm build, because you provide a way to generate an individual deb too. This is my desperate attempt to avoid having to use a dockerized application! (never mind the build process itself uses docker... but does that mean my production environment has to, too?)

[joshuaboniface]

So to clarify that point, no - we use Docker containers to build all of our binaries because they provide a customizable, clean slate for each one. Without that, we'd need to run separate VMs/workers for every possible OS we support which isn't feasible. Docker containers let us run on a parent host and pull a container with whatever base OS, dependencies, etc. we need inside of it, then it spits out a binary package we can import into our repo.

I understand the desire to get on 10.9, but I'd honestly suggest just working with the RPMFusion folks to get 10.9.0 building and get their build up if you want to expend the effort on this. Again to recap really simply, I'd really rather not have RPM specs and a Fedora/etc. build process back in our official packaging, just like we don't want Arch specs, Gentoo ebuilds, or NixPKG specs in here either. It's not a dig against you, it's just a matter of what we can reasonably support over time and the lack of tooling available to let us go "all the way" with it (i.e. an RPM repo manager tool).

[TimGels]

We will not be providing or hosting RPM builds/ packages.