On Wed, Jan 29, 2025, at 3:56 PM, Matthew Miller wrote: > On Wed, Jan 22, 2025 at 09:51:28AM +0000, Daniel P. Berrangé wrote: >> While the ring idea as presented there didn't come to exist inside >> Fedora as a community, I think we can see that concept has indeed >> grown up outside Fedora. > > Yes, 100%. This was already happening when I made the Rings proposal back in > 2013. Fedora has always been a project that cares about more than just the > core — literally so, with Core/Extras and then the merge of those. The Rings > proposal was intended to keep us relevant at the higher layers too. > >> 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. > > Again, yes, 100%. > >> 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. > > I am subscribed to your newsletter. > > At this point, I think the fundamental question is: is it too late? Not with > Rings, necessarily — can we provide these benefits in _any_ meaningful way? > > For end users? For developers building on Fedora Linux? > > Or viewing it another way: for applications? For development environments? > > If we have the _internal_ ability, do we have a meaningful chance to effect > outside change — if we build it, will they come?
Adopting Python in Fedora improved the entire Python ecosystem, so yes it is possible. Arch linux and FreeBSD have a clear set of core packages, and policies to make a package a core package. If a package is heavily used directly, or is a dependency for many other packages, some care should be taken in how it is delivered. Protobuf is an example package that has been widely adopted as a dependency in other packages, but the update policy and ABI and API stability guarantees are such that using alternative implementations should be preferred as it means bundling is not needed. > > Are we _currently_ providing meaningful benefit by building end-user > applications that are available directly from their upstreams in Flathub, or > via Docker images? Many mobile and edge devices often have limited storage and RAM, so efficient packaging systems are a big win. > > What do we gain from building, say, Inkscape ourselves — other than allowing > us to check the boxes of our own rules? Is it worthwhile to try to package > Home Assistant? And, not, like, quixotically worthwhile — what impact does > it have? > A recent survey of Android packages where bundling is default indicates that dependencies rarely get updated: https://app.media.ccc.de/v/38c3-ultrawide-archaeology-on-android-native-libraries Being able to run a lot of software is great. Packaged software tends to have higher quality. For many users, the latest feature is rarely enough of an incentive to use the development version. Packaging the software also tests the dependencies it uses, giving a more robust core. Is it possible to create better tooling to build packages? Python in Fedora is good, most dependencies are automatically resolved. It is unclear if one could automate checking the possible compatible versions, with C there are ABI compatibility tools that can help, API tools could possibly help for interpreted languages. GitHub does have bots that encourage upgrades of dependencies for some language ecosystems - can his be done in Fedora for cases where bundling is done? > If we stopped doing these things, what would it make room for? > Are there incentives to maintain, improve and develop tooling? Checking licensing compliance is important, but there is some overlap in building packages and flatpaks. Packit is a good first step in improving tooling, Open Build Service does something similar. Maybe some co-ordination is needed? More effort on tooling that produces a spec file from a build system and then documenting and advertising the existence of such tools would probably increase efficiency and the quality of the Fedora distribution. Bundling by default is not a solution. Some bundling is needed when adding new features, but it should be the exception rather than the norm. -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
