Announcement

Collapse
No announcement yet.

Flatpak 1.5 Released With Version Pinning, Self-Updates In Portals

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by andyprough View Post
    Why are flatpak devs unable to use github to host their repositories? Is this a bit of trickery by RedHat to control developers by forcing hosting on flathub?
    1. Because they need to publish entire directory trees, not just files. The same reason you cannot host yum or apt repo on github.
    2. Redhat has nothing to do with flathub; it is not even shipping in RHEL or Fedora, you have to add it yourself.

    Comment


    • #12
      However Snap is designed to work at a lower level rather than just desktop application like Flatpak, I mean those aren't in competition between them. Snap is more in competition with systemd-nspawn, but I am pretty sure the Poettering was working to a docker-like solution for systemd but I don't remember the name (maybe it is exactly nspawn). The big point of Snap is the ready made configuration already available in it so you can just install and you are ready to go.

      Comment


      • #13
        Originally posted by lu_tze View Post

        1. Because they need to publish entire directory trees, not just files. The same reason you cannot host yum or apt repo on github.
        2. Redhat has nothing to do with flathub; it is not even shipping in RHEL or Fedora, you have to add it yourself.
        Even then, a big upside of having public manifests on GitHub is that anyone can build and run them locally

        Comment


        • #14
          I prefer to use rpm or deb, but the few times I used snap and flatpak, I found myself better with flatpak. With snap I have always had some problems, moreover I use openSUSE and flatpak support is simply to be enabled, while for snaps it is necessary to install the support manually.

          Comment


          • #15
            Well, first of all, I've never been able to get a Flatpak or Snaps program to work.

            And second, even if I were able to I just don't see how running every program in it's own isolated environment is a wise or efficient way to do things. I'm all for interoperability of programs across all Linux platforms, but surely there's a better way.

            Seriously, Flatpack and Snaps feel like building a Space Shuttle to go to the local 7/11.

            Comment


            • #16
              Originally posted by lu_tze View Post
              1. Because they need to publish entire directory trees, not just files. The same reason you cannot host yum or apt repo on github.
              2. Redhat has nothing to do with flathub; it is not even shipping in RHEL or Fedora, you have to add it yourself.
              Makes sense, thanks for the clarification. I guess these are the compromises that RedHat had to make when they decided to make a platform for smashing proprietary and libre code together into these hybrid licensed mashups. Would have made sense to do something like this, but only allowing compatible licenses to be combined into a package.

              Comment


              • #17
                Originally posted by Calinou View Post

                Even then, a big upside of having public manifests on GitHub is that anyone can build and run them locally
                Flatpak does provide the source manifest for all installed packages by default as well, so you can always repackage any application which you've installed - as long as you have access to the sources that were originally used to build it.
                You can find the source manifest under the installed application files, at /var/lib/flatpak/app/<APP ID>/current/active/files/manifest.json or ~/.local/share/flatpak/app/<APP ID>/current/active/files/manifest.json for the system and user installation respectively.

                Originally posted by andyprough View Post
                Why are flatpak devs unable to use github to host their repositories? Is this a bit of trickery by RedHat to control developers by forcing hosting on flathub?
                Originally posted by lu_tze View Post

                1. Because they need to publish entire directory trees, not just files. The same reason you cannot host yum or apt repo on github.
                2. Redhat has nothing to do with flathub; it is not even shipping in RHEL or Fedora, you have to add it yourself.
                Apart from that, OSTree repos - what Flatpak uses for remotes - are able to be formatted for regular static serving, so any web server that allows direct file access is able to host one, GitHub/GitLab pages included. (Though I doubt they'd be happy about having their system (ab)used for such a purpose)

                Comment


                • #18
                  Originally posted by muncrief View Post
                  Well, first of all, I've never been able to get a Flatpak or Snaps program to work.

                  And second, even if I were able to I just don't see how running every program in it's own isolated environment is a wise or efficient way to do things. I'm all for interoperability of programs across all Linux platforms, but surely there's a better way.

                  Seriously, Flatpack and Snaps feel like building a Space Shuttle to go to the local 7/11.
                  Flatpaks have numerous advantages over "native" packages, in my opinion for desktop applications they're superior.
                  • They let developers chose what versions of libraries they target (without needing to "bundle" or mantain most of them). If distro X has version 2 of library, but the app needs version 1 of a library, distro X can still use said app. The fast moving target is gone and when the application is ready it can be upgraded to use version 2.
                  • They organize application files neatly in their own folders. It doesn't need to rely on a package manager to track what gets extracted into /usr and then try and do the reverse when the app is uninstalled. They also work when /usr is read-only. /usr being read-only is more popular than you probably think and is probably going to the norm sometime in the future.
                  • They let slow-moving distros (e.g. RHEL, Debian) have up to date applications, without risking the stability of the host.
                  • Because of how Flatpak apps store data, you can see how much data an app is using and clear it. This has the potential to make roaming profiles on Linux a lot easier, plus the sandboxing can force apps who are not respecting the XDG directories to have their storage kept tidy.
                  • Flatpak-builder manifest imho are much easier to read and write than rpms, debs.
                  • They let application developers skip the distributions and ship apps/updates straight to users in a secure, reliable and decentralized way.
                  • Users can also install apps to their home dreictories with full integration.

                  Originally posted by Ananace View Post
                  Flatpak does provide the source manifest for all installed packages by default as well, so you can always repackage any application which you've installed - as long as you have access to the sources that were originally used to build it.
                  That's not part of Flatpak, it's actually part of flatpak-builder. Flatpaks do not have to be built with Flatpak-builder (Fedora flatpaks and the XDG/GNOME runtimes are not)
                  Last edited by Britoid; 03 October 2019, 01:04 PM.

                  Comment


                  • #19
                    I'm enjoying this polite and informative discussion It's nice when Phoronix forums are like this.

                    Comment


                    • #20
                      Originally posted by Britoid View Post

                      That's not part of Flatpak, it's actually part of flatpak-builder. Flatpaks do not have to be built with Flatpak-builder (Fedora flatpaks and the XDG/GNOME runtimes are not)
                      Yes, I should've been a lot more clear on that point, "by default" was meant to be in relation to using "the default" of flatpak-builder.
                      You're after all able to do the packaging however you want using the flatpak suite of tools, and JSON/YAML manifests are only used by flatpak-builder itself, which then makes a whole lot of sense why you'd only find them in packages built with flatpak-builder.

                      Comment

                      Working...
                      X