Announcement

Collapse
No announcement yet.

Fedora 27 Could See More GUI Apps As Flatpaks

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

  • #11
    Originally posted by Zan Lynx View Post
    Bah. Humbug.

    I still see Flatpaks as completely useless, a reinvention of already existing wheels, and something that could have easily been done using RPM or DEB already.

    An existing packaging system could have supported it by creating virtual packages that declare what library interfaces have to be installed for each support level.

    These Flatpak things are merely a newer fancied up version of LSB and chroots and that never went anywhere.
    You cannot install as non-root, you cannot install cleanly multi-versions, RPM is distro-dependant, it's not sandboxed....

    Comment


    • #12
      Originally posted by woprandi View Post

      You cannot install as non-root, you cannot install cleanly multi-versions, RPM is distro-dependant, it's not sandboxed....
      Go see if you can install a new Flatpak runtime base without being root... I am pretty sure that you can't.
      Sandboxing is a feature of running the program. Any program can be packaged for sandboxing. Like the "bind-chroot" package in Redhat / Fedora has a launch script for bind / named that runs it in a chroot. It could easily be a namespaced container if someone added that to the chroot setup.
      Multiple versions are easy in RPM or DEB. It is just a naming problem. There can be only one thing named "firefox" in the package database so if you want an older version you have to name it "firefox35"
      So with such wonderful multi-version Flatpak support how exactly is it supposed to act when you launch "Firefox" at the GUI? It has to just pick one for you. Probably the newest one. Haha, right here this is already a problem: https://github.com/flatpak/flatpak/issues/460

      Comment


      • #13
        Originally posted by Zan Lynx View Post
        Bah. Humbug.

        I still see Flatpaks as completely useless, a reinvention of already existing wheels, and something that could have easily been done using RPM or DEB already.

        An existing packaging system could have supported it by creating virtual packages that declare what library interfaces have to be installed for each support level.

        These Flatpak things are merely a newer fancied up version of LSB and chroots and that never went anywhere.
        While he didn't develop Flatpak, Poettering did propose the Flatpak approach back in 2013 and write an article about it in 2014, so I'm assuming it's the package manager version of what made PulseAudio and systemd successful:

        This forest of solutions has been in political deadlock for too long and we can't break it. Let's learn from R. Buckminster Fuller [2] and enact change, not by fighting the status quo, but by producing a new alternative with characteristics so desirable that it will obsolete the entire squabbling mess within a given scope.

        Comment


        • #14
          Originally posted by Zan Lynx View Post
          Go see if you can install a new Flatpak runtime base without being root... I am pretty sure that you can't.
          # flatpak list
          Ref Options
          org.libreoffice.LibreOffice/x86_64/fresh user,current
          org.pitivi.Pitivi/x86_64/stable user,current
          org.gnome.Platform/x86_64/3.20 user,runtime
          org.gnome.Platform/x86_64/3.22 system,runtime


          Comment

          Working...
          X