I’d like to submit a proposal to the community to improve Fedora’s package ecosystem and make the process of requesting new software more accessible.
Current Situation
Currently, when a user needs a package that isn’t available in the official repositories, the only option is to become a maintainer and manage the package independently. This approach an important limitation: not all users have the technical skills for RPM package compilation and maintenance. In addition, many users prefer using native RPM packages rather than alternatives like Flatpak and Fedora’s RPM ecosystem is more limited compared to some other distributions.
The Proposal
I would suggest implementing an open and democratic package request system that could work as follows:
Key Features:
Structured request form with fields for:
Software name and description
Upstream project URL
License information
…
Community voting system to establish request priorities
Transparent ranking of the most requested packages by the community
Voluntary matching between available maintainers and priority requests
Benefits:
Volunteer maintainers could choose which packages to maintain based on actual community demand
Greater transparency about user needs
Opportunity for non-technical users to contribute to Fedora’s ecosystem growth
Better allocation of development resources
Implementation
The system could be implemented in two ways:
Immediate solution: Using the existing Fedora Discussion platform with structured tags and procedures
Long-term solution: Integration into the upcoming Fedora Forgejo
Discussion Questions
Do you find this proposal useful for the Fedora community?
What other aspects should we consider for such a system?
Are there maintainers interested in participating in a potential pilot phase?
Are there similar solutions in other distributions we could learn from?
I’m very interested in your feedback and available to collaborate on further developing this idea.
Thank you for your attention and have a great day!
This proposal stems from the desire to make Fedora even more open and community-oriented, facilitating access to a richer software ecosystem for all users.
I think that’s the critical point at which a system like the one you propose would fail. Most existing package maintainers are just not looking for additional work, because they’re already over-committed
But getting more input about which things are currently missing from Fedora would still be nice.
Not doubting what you say about package maintainers, but using this as an opportunity to make a more general point - I think it would be useful for Fedora teams to put out more “Help Wanted” ads about specific tasks where they are seeking volunteer input.
Currently the “get involved” process is more oriented around steering yourself (or asking others to steer you) to a team that fits your skills. But sometimes - especially with more generalist skillsets - it’s easier to say “yep, I know I can take on that specific task” rather than “I know I would fit well into this team [whose overall responsibilities and work queue aren’t necessarily familiar to me].”
As far as I can see, this is the way it works now.
Connecting with those volunteer packagers could be process for improvement.
Great issue to discuss though. My favoured approach is the community raising issues, and a BDFL or group of highly competent people make the final choice.
You can only have a BDFL if there are people they can dictate to.
Outside possibly of people who are employed by a company such as RedHat to work on Fedora none of our maintainers can be ordered to package particular things and even people who are employed to work on it only get told what to do by their employers not by the community.
I fear this whole scheme is based on a total misunderstanding of how the packaging community works in that it assumes people set out simply wanting to package “something” and need guidance on what to package when it reality most of us package things because they interest us or we want to use them ourselves.
Linux packagers are a scarce resource, so any request for a new package should only occur after a packager (and preferably more than one) willing to take on the task has been identified and a copr repository created so users can try the package before it is included in Fedora. This will promote a more
informed discussion of potential conflicts with Fedora existing packages. Before retiring, I spent a lot of my time dealing a differences in available libraries and configuration options affecting our “mission-critical” applications (open source, but only useful to a small scientific community scattered across the globe, so never a candidate for inclusion in a distro).
A wishlist does exist, but is just not used too much primarily because we package maintainers tend to limit ourselves to packaging stuff we use—otherwise there is little testing of the packages, and little incentive for us to keep working on them in our free time.
The Neuro SIG, for example, does have a ticketing system where we ask community members to let us know what packages are useful to them. We then go through them and package them up:
The issue remains the same. There is just too much software out there, and a handful of people cannot package and maintain it all. It just does not scale.
As a case in point—the Neuro SIG was maintaining >300 packages with generally 3 active package maintainers. It got to a point where we could no longer keep up with it and so now we’re dropping lots of Python software that users can directly install from PyPi to reduce our workload:
People have looked at automating these. The Rust SIG has a handy rust2rpm tool that can generate specs from cargo sources:
The Python SIG has also experimented with automatically building all packages in PyPi as rpms, but got mixed results.
So, human intervention is necessary, if only for validating licenses.
We did have the easyfix page that collected relatively simpler tasks for newcomers to work on:
It didn’t quite work, because it relies on:
humans marking issues to make them appear on the list
newcomers being able to take on these without any domain/contextual knowledge
Neither of these requirements are necessarily true in all conditions. So, again, human intervention is required. Someone that wants to do something does need to know a little bit about how things work. That’s why the Join SIG moved to a human centric flow—if you speak to people, you will learn what/how/when/where/why things are done.
People that already know can skip this—it doesn’t hold anyone back.
We can and absolutely should encourage teams to mark more tasks with tags and so on. Some will do it, some won’t—that’s the bit that we can never control.
For the wiki? you need to be a member of at least one SIG to edit. If you want to do that, we in Join can offer you a temporary membership with us to help with that.
Another practicality, unfortunately. We got so much spam on the wiki that the infrastructure team had to disable default write access to it. So one now has to gain access to some Fedora team/group on the account system as a way to manually verify that the account is genuine, and that gives one write access. The Join SIG does provide this, as Mat noted.
One doesn’t have to use the wiki tbh. A post here saying “this is a useful package, would someone like to package it?” would do. We could even start a dedicated topic here for “interesting software that would be good to include in Fedora” if that would be easier. Or an issue tracker somewhere (since pagure is going away soon)—where everyone can open tickets (similar to the neurofedora tracker).
All of this goes with the same caveat: it doesn’t mean it will get packaged, unless a package maintainer decides it’s worth their time. (And someone will have to keep an eye on the spam).
I thank you for your valuable opinions and suggestions. Given the current situation, I think it is useless to have access to the wiki, but thank you for inviting me to your SIG.
At this point the major obstacle seems to be the manteiner’s scarcity, but on this I have no valid proposals at the moment.
I’d love some comprehensive (and easy!) docs on packaging. I tried once, got stuck and gave up I’d be willing to give it another go though… If I could sort of understand it before jumping in.
This feels like gameification of the processes, and is (all too easily) abused by those with an agenda (and there is always someone with an agenda).
In any case, as others have stated, there is simply not any real available pool of people looking for more volunteer packaging work (if only Fedora had the luxury of people just waiting for something to do with their free time!). Some enterprise distributions (at high commit $$$$ levels) do have a way to get the distro to build/support packages going forward, but it is all about (in effect) paying for the work.
Funding development and packaging and support is a big issue with open source. While targeted towards infrastructure costs, OpenSSF just published a doc on that fact that those costs are not, really, free. If one can find a way to compensate those (such as developers and packagers) for their efforts, it is possible more would want to spend their resources on such (a badge for supporting 10 packages cannot be spent at your local coffee shop).
I once started writing down some instructions on how to get started with packaging for Fedora. I tried to focus on one task at a time, so it could be digested more easily. If you can tell me what is unclear or missing, I’ll work on beefing that up some more.
To be honest, the term “request” in the proposal title triggered me quite a bit; the wording of the proposal made me calm down as I saw its good intentions
Most packagers are volunteers. I’m not sure whether most packages are maintained by volunteers, but broadly speaking we have to groups of maintainers:
volunteers
employees of RedHat or other companies
The first group is motivated by doing what they enjoy, and/or by maintaining what they need or want in Fedora.
The second group is usually responsible for a certain employer’s interest, such as keeping a specific software stack working.
There’s a non-empty intersection, and some employers grant their employees to spend part of their work time to “do what they want if it’s FLOSS/Fedora/…”.
Any of these come with a clear “want” or motivation. I’m afraid there’s just no (sizable) group which would take on these requests.
Another aspect: We have too many “trivial” packages already, i.e. those “user apps” which could be installed just as well by an ecosystem tool per user (fonts, pip, cargo, flatpak, …); we’re basically in the middle of an evolution from a package centered distro to a distro as a platform. The present request hinders this more than it helps.
If these are the assumptions, then we should remove from the repositories all the apps that are also available as Flatpaks and leave only system packages. In practice, however, many users prefer to use RPMs for various reasons. I, for example, find it pointless to sandbox open source software, which, by definition, is safe by default. I find that Flatpak is much more useful for integrating proprietary software. Several users prefer RPMs for reasons of space, performance, and other factors. I’ve seen tools around that allow automating the package building at every update: if this were achievable in Fedora, it would practically solve every problem (maybe); this way the maintainer would only need to intervene in case of problems during testing. But I don’t know if something like this could be part of the project’s plans.
PS: Perfect automation would be building + push to testing. This way the maintainer’s workload would be drastically reduced (at least I believe so) and each maintainer could assign themselves an unlimited number of packages (I hope I’m not being too optimistic).
Ha, out of the 4 ecosystems that I mentioned you picked the last one. flatpak was not meant as a bait. But here you go:
I’m all for open source. I’m all for rpms.
But an rpm that is built in an automated way from upstream sources without maintainer’s involvement is in no way better than a flatpak - you put all trust in the upstream. (In which case it better be sandboxed.)
Things are just not as simple as “open source is safe by default”.
I’d be willing to give it another go though… If I could sort of understand it before jumping in.