On Wed, Jan 25, 2023 at 06:01:17PM +0100, Vít Ondruch wrote: > > Dne 25. 01. 23 v 15:59 Josh Boyer napsal(a): > > On Wed, Jan 25, 2023 at 5:56 AM Vít Ondruch <vondr...@redhat.com> wrote: > > > I am not user of Bottles so I won't complain about this particular case, > > > but the push towards (upstream) Flatpaks is unfortunate :/ > > Can you elaborate on why you feel that way? > > > I don't trust upstream Flatpacks. I don't trust they follow any standard > except standard of their authors. > > And I don't like Flatpacks, because their main advantage (their isolation) > is also their biggest disadvantage. There can't be both without making > compromises. If I am not mistaken, the isolation is also mostly myth, > because it is disabled in most cases.
Looking at Flatpaks with both my upstream author hat and distro maintainer hat, the main advantages I see is not the isolation. It is that they have the potential to eliminate the massive amount of duplicated work between every distro re-packaging the same app, and ensure more timely availablity of new releases to end users by de-coupling from the distro release cycle. As an upstream author, I want the latest releases of my software to be available for users to install as quickly as possible. Distros largely aren't satisfying that desire as well as I would like. If I rely on distro packaging, there can 3-12 month delay before a distro gets my new release in front of a user depending on their release cycle. Then there is the problem of distro maintainers not packaging the app correctly by forgetting to correctly handle/enable new build deps. Or a distro maintainer ceases to have time to work on it, leaving users stuck on outdated releases indefinitely. Or any one of the 3rd party libraries my app relies on may be outdated. Maintaining a OS distro to a high standard takes alot of resources, and there are an uncountable number of Linux distros out there which users may end up using, which just amplifies the amount of resources needed. The sad thing is that they're essentially doing the same work over and over again, just with a different package format, all to end up delivering a user experiance that is largely identical when it comes to the desktop interface. Except that doesn't end up being identical largely due to problems with keeping packaging up2date with limited distro resources. No one distro ends up doing it right for every app, which is frustrating as both a user and upstream app maintainer. So flatpaks have the promise of getting get of a huge amount of duplicated effort at the application layer, allowing desktop apps to be packaged once and run anywhere. This shouldn't be read as saying distros don't add value. They certainly do. The ability to curate a set of software, such that users can choose to only install OSS packages is valuable. Users have greater confidence of quality in the distros, even if that is sometimes misplaced. The distro maintainers have also frequently highlighted problems to upstream wrt licensing of code. The distros have driven the security response processes to vulnerabilities too, which is especially valuable for the long tail of pacakges which don't have a dedicated upstream vulnerability handling process. There are many things distros have done well, but the amount of effort spent by distro maintainers to achieve this is enourmous and inefficient. When building flatpaks, while an upstream author may be well placed to build their own app and update it whenever there are important changes, they may not want to keep track of all the 3rd party library deps they build on top of. The flathub.org build gives you a base runtime, which for a GNOME app may have 90% of what you need to depend on, but there are usually still extra libraries to add. It is desirable to be able to re-issue application flatpaks whenever the base runtime, or any of the extra libs get updated. The distros should be able to add value here by providing the base runtimes, and by ensuring all likely library deps are pre-packaged, and being able to re-issue flatpaks anytime a dep gets updated. This should not require the distros to take on the job of actually writing flatpaks for the application leaf nodes though. Flatpaks have the promise of being able to benefit both the upstream authors and the distro maintainers, if we can figure out the right tradeoff. Keep the best aspects that distros provide, while reducing the amount of work distros have to do by avoiding need to re-package every leaf-application in distro specific formats. The tragedy would be if every distro ends up re-doing the creation and shipping of flatpaks, just as they do today with the distros specific packaging formats. 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@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
