KDE will have to choose between Flatpak packages and snap packages

KDE-Logo

A few days ago we saw how KDE developers launched snap packages of their applications, being one of the desktops to get into this format. However, when we all thought it was going to be KDE's preferred format, we read a few words on a KDE developer's blog that portend future trouble for KDE and Plasma users.

The virtues of this type of package are indisputable and the developer in question, Sebastian KuglerYou do not doubt it, but if you affirm that in the future, KDE will have to choose between one format or another to optimize its efforts and workloads.

So, in the not too distant future, KDE will have to choose between launching packages in Flatpak or Snap packages. A dilemma that more and more developers face and that some desktops like Gnome, quickly solved.

Flatpak might be the format of choice for most of the KDE Community

Kügler in His article states that the desktop should choose Flatpak for its transversality between distributions, but it is true that currently development in Snap is more advanced than in Flatpak. In any case, the interest of the KDE community is because the desktop is available in as many distributions as possible, something that seems more possible with Flatpak than with snap packages, which require tools created by Canonical.

The entire KDE community has not yet spoken about it, but as Kügler says, like it or not, they will have to opt for one format or another. I personally believe that the moment of choice will come, but Kubuntu is a very active community and they will surely make the snap package survive in KDE, just like OpenSUSE and Fedora KDE users with the Flatpak format, so regardless of the choice, there will always be someone in KDE who will keep both formats, but Which users will they choose?


Leave a Comment

Your email address will not be published. Required fields are marked with *

*

*

  1. Responsible for the data: AB Internet Networks 2008 SL
  2. Purpose of the data: Control SPAM, comment management.
  3. Legitimation: Your consent
  4. Communication of the data: The data will not be communicated to third parties except by legal obligation.
  5. Data storage: Database hosted by Occentus Networks (EU)
  6. Rights: At any time you can limit, recover and delete your information.

  1.   Luis said

    What news nonsense is this?
    There are thousands and thousands of programs that are packaged by collaborators / distribution workers, what difference does it make if KDE stops distributing one, the other or both?
    It gives the feeling that you want to provoke fear and controversy among the readers in order to get visits, and I am not going to tell you that it seems bad, but in this case there is no where to take it.

    1.    Charles said

      It is only an assessment on the choice of an important framework over official packages.

      Understanding the operation of new technologies basically encourages the distribution of applications to be granted directly by their developers, thus the "package maintainers" as we understand them today are left out. Eg The X package in Flatpak format would be the same one officially distributed by KDE in Fedora and OpenSUSE. Otherwise it would be to lose the initiative and go back to business as usual (unnecessary extra work)

  2.   flattened said

    Is that the new packaging system opens the possibility for the developer to make the packages and keep them updated. So the controversy makes perfect sense. If KDE decides to distribute in one format, other contributors will have to create the other's if they are interested. And of course, they will always be behind.

  3.   Charles said

    It was recently announced that KDE Discover will have support for both Flatpak and Snap packages (the benefits of appstream, packagekit, etc). However, considering that its new flagship distro is KDE Neon which is based on Ubuntu, it is much easier to implement Snap and even the mixed support of Snap / Flatpak on the system.

    The modularity, ease of use and independence of Flatpak give it a great advantage over Snap and I do not understand where they get from the article that Snap is currently more advanced than Flatpak today, since it is the opposite. Even following the history of changes of both, Snap little by little changed its vision following the same parameters that Flatpak proposed as a solution and that "curiously" were criticized by them at the beginning.

    I'm not guessing a winner, but I've seen more work and interest around Flatpak.