On Wed, Jan 22, 2025 at 09:51:28AM +0000, Daniel P. Berrangé wrote: > An increasingly large part of the ecosystem is working and deploying > a way that Fedora (and derivative distros) are relegated to only > delivering what's illustrated as Ring 1. This is especially the case > in the CoreOS/SilverBlue spins, but we see it in traditional installs > too which only install enough of Fedora to bootstrap the outside > world. Meanwhile ring 2 is the space filled by either language specific > tools (pip, cargo, rubygems, etc), and some docker container images, > while ring 3 is the space filled by Flatpaks and further docker > container images. Fedora meanwhile continues trying to package and > deliver everything the same way as we did for decades, as if this > shift were not happening. Hi Daniel, It is certainly true that users are using those layered installation methods… But I don't think this is new in any way. In the past we had: - people building their own C apps and kernels and whatnot, - ndiswrapper because we were missing drivers for basic hardware, - wine to run various crucial software, e.g. gvmt-provided tax suites, - mandatory livna/freshrpms/dribble/rpmfusion, - people using pip and 'sudo pip' and breaking system python… The pressure to extend the system install with additional installation methods is a constant. > Fedora (and derivative distros) are relegated to only delivering > what's illustrated as Ring 1 So I don't agree that this is true. Fedora in its basic form is more usable than ever. A few years ago we embraced the inclusion of Flatpaks as an official installation method, and external repos for some missing drivers, and with those, we filled some important gaps. I think that as memory fades we lose track of some of the really ugly things users needed to do to use Linux. OTOH, downstreams like RHEL are relegating themselves to just being Ring 1. There are good reasons for this, but in some ways it's a self-inflicted limitation. Fedora has different considerations and doesn't need to follow those steps. > What's disappointing is that as end users are adopting use of things > from Ring's 2 & 3, they are loosing the potential benefits Fedora's > more direct involvement would have enabled. The easy-of-use, quality, and flexibility one gets from system packages is unparalleled. But we get that quality _because_ we have the annoying process. We take the upstream software apart into basic pieces and put it back together cleanly. If we embraced upstream packaging methods and the distro was just a thin wrapper that repackaged upstream releases into a slightly different format, we'd gain the short run, but lose in the long term. Thus, I agree that we need to keep changing and adapting. The way we build packages needs to become simpler and faster. We're doing that to some extent, but we always need to do more. But there are good steps: for example the embracing of declarative dependency description in the Python world, integrating upstream and distro packaging, is a win for everybody. There are also bad steps… An example is any case where we say that the upstream is just too messy and unwieldy and we have no choice but to accept the mess and just repackage things without control. Like with vendored dependencies. In the short run this may be unavoidable, but in the long run everybody loses. Zbyszek -- _______________________________________________ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
