On Thu, Jan 30, 2025 at 11:31:33AM +0300, Benson Muite wrote: > 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: > > 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. The thesis that packaged software is better tested or higher quality is *not* clear-cut. There are lots of factors that contribute to this and some favour upstream and some favour downstream. Downstreams certainly find bug that upstream misses, especially cross platform portability, since even today downstreams usually have access to a wider variety of architectures than upstreams do. Ideally these local bugs even get diagnosed & resolved, but that varies depending on the skills & available time of the maintainers. Downstreams also deliver value cherry-picking patches at arbitrary points in time, so users don't need to wait for a often fixed upstream release schedule. This is potentially the biggest selling point for downstream in terms of delivering quality value-add. Though again it varies depending on time availability of the individual maintainers. Where downstream usually looses, IME, is in relation to automated functional testing. For non-trivial projects, it is increasingly common for upstreams to have extensive functional testing CI systems. These are proving functional correctness against a chosen set of dependency versions. If downstream diverges from the chosen set of dep versions, they will almost certainly introduce functional correctness flaws that are not present in the upstream validated deployment scenario. Downstream might have (unknowingly) fixed some functional problems too by virtue of having newer dependencies, but unless downstream is running the same functional CI harness, no one will ever be sure if this is a net win. So overall it is not a given that having downstream use different dependancy versions, and cherry-picking patches, into pacakges is going to result in a higher quality product than using an upstream provided container image/flatpak. Or at least there are different interpretations of "quality" in this context. You can make a case that downstream would be a more secure product, as downstreams often cherry-pick CVE fixes more promptly than upstream does releases. You can't make the case that downsteam would be a more functionally correct product unless downstream has done at least the same amount of functional testing as upstream. The relative testing upstream vs downstream varies tremendously across our distro packages in both directions. So yes, distro packages can deliver a higher quality application in theory, but in practice this is far from a certainty. Bundling deps has the potential (not a guarantee) to enable the best of both worlds. Using the versions validated by upstream as functionally correct, while downstream can still deliver value add through cherry-picking further bug and security patches. > 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. ABI & API compatibility is very important as a first step, without which you're dead in the water. It is insufficient, however, to ensure a high quality delivered pacakge. As application complexity increases, API/ABI compat becomes less & less sufficient. Functional testing becomes king. Taking a large project I was previously involved in, OpenStack. When we tried to make that work on top of Fedora with the packaged python versions, it was a never ending battle against bugs that were only seen in Fedora. This is in versions of python deps that were (usually) declared compatible, but none the less had flaws that were impacting the app. Upstream may hit the same bugs eventually if they updated their deps versions, but at any point in time, using the exact matching upstream tested deps gave you a more functionally reliable deployment. Fedora maintainers didn't have the resources to run the same level of CI testing as upstream to identify bugs unique to our versions, let alone fix issues that it would have found. In the context of RHEL we had much the same issue, but we did have the resources to invest in automated CI testing against the downsteam deps versions. Having a slower moving distro in terms of version rebases also helped. This let us identify & resolve RHEL only bugs before the result shipped to users, thus genuinely being able to claim to deliver a higher quality result. It was (& still is) a massive testing effort. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- _______________________________________________ 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
