Re: Retiring Bottles in favor of Flatpak provided by upstream

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <vondruch@xxxxxxxxxx> 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@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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux