Removal from the Inkscape Website · Issue #87 · flathub/org.inkscape.Inkscape
github.com
The inkscape project is considering removing the flatpak format from the website's resources/downloads pages because of lack of maintenance. There is no maintainer of the flatpak/flathub format at ...

The Flatpak is already packaged and works well. It just needs to be maintained from a person that joins the Inkscape community.

This would allow further improvements like Portal support and making the app official on Flathub.

Update: One might have been found!

      • SayCyberOnceMore@feddit.ukEnglish
        6·
        6 months ago

        Well… of course only time will tell, but the fact that we’ve been doing that for sooo long… (me for ~20 years?) would imply that it might just be around for longer than snap/flatpak/etc

        Of course, sometimes it’s disguised as yay -S…

      • Chewy@discuss.tchncs.de
        26·
        6 months ago

        I’d say flatpak isn’t the future because it’s already here and seems to be universally accepted as the cross-distro package manager.

        I do like how the Nix package manager handles dependencies, but it’s not suitable for app developers packaging their own apps because of its complexity.

        If a better flatpak comes around I’d use it too, but at least for graphical apps I don’t know what it’d have to do to be better. In my opinion, flatpak is a prime example of good enough, but not perfect and I’d be surprised if there was a different tool with the same momentum in 15 years (except snap, but they seem too Ubuntu specific).

        • QuantumSoul@lemmy.dbzer0.com
          6·
          6 months ago

          Snap is shit. I started using flatpak because apt didn’t support apps that I wanted and snap only supported ancient releases. .deb is annoying too and .appimage I don’t like to have the files hanging there

          • Possibly linux@lemmy.zipEnglish
            2·
            6 months ago

            I left Ubuntu when apt wouldn’t let me install a native package. It just would redirect to a broken snap.

            • Daeraxa@lemmy.ml
              2·
              6 months ago

              Not officially but people have managed to reverse engineer it before in order to host their own - https://forum.snapcraft.io/t/lol-an-open-source-snap-server-implementation/27109

              Whilst I do get the sentiment (and in no way do I support Canonical in keeping it proprietary), how likely is it that alternative Snap repos are going to show up if they did make it possible? Even with Flatpak where it is encouraged and documented I don’t think I’ve heard of anyone setting up a Flathub alternative of any significance.

              • Gamma@beehaw.orgEnglish
                4·
                6 months ago

                elementary has their own repo for their system apps

                I didn’t know about the self-hosted snap stores, thanks for pointing it out!

                • Daeraxa@lemmy.ml
                  2·
                  6 months ago

                  And I wasn’t aware of the Elementary thing with Flatpak! Admittedly I hadn’t really thought of it in that way, I was thinking something more akin to F-droid where there are a couple of extra repos you can add which have applications not on the main one due to slightly looser requirements. But making it specifically for apps for that ecosystem in particular makes a lot of sense.

          • woelkchen@lemmy.world
            6·
            6 months ago

            For what it is worth you can install Snap on most distros. https://snapcraft.io/docs/installing-snapd

            Snap is a cesspool for malware and shovel ware. The best apps are packaged by Canonical. Also, when people still cared about Snap, there were frequent reports of incompatibilities because it was developed with Ubuntu in mind.

          • BennyHill500@lemmy.ml
            1·
            6 months ago

            but you shouldnt because snap’s "strict confinement’ sandbox feature does not work without the legacy patches to Apparmor that ubuntu uses.

    • yukijoouFrançais
      6·
      6 months ago

      it sure seems like it though

      i mean, they’ll never replace system package manager, but for desktop applications, flatpak is honestly quite good

      • bigmclargehuge@lemmy.world
        4·
        6 months ago

        (Not incredibly educated on Flatpaks, please educate me if I’m wrong) My main issue with Flatpak is the bundled dependancies. I really prefer packages to come bundled with the absolute bare minimum, as part of the main appeal of Linux for me is the shared system wide dependancies. Flatpak sort of seems to throw that ideology out the window.

        Let me ask this (genuinely asking, I’m not a software developer and I’m curious why this isn’t a common practice), why aren’t “portable” builds of software more common? Ie, just a folder with the executable that you can run from anywhere? Would these in theory also need to come bundled with any needed dependancies? Or could they simply be told to seek out the ones already installed on the system? Or would this just depend on the software?

        I ask this because in my mind, a portable build of a piece of software seems like the perfect middle ground between a native, distro specific build and a specialized universal packaging method like Flatpak.

        • yukijoouEnglish
          3·
          6 months ago

          well, the point of flatpak is to have bundled dependencies so they run predictably no matter the distro

          if one of your software’s dependency gets updated, and your software isn’t, you may run into issues - like a function from the library you’re using getting removed, or its behaviour changing slightly. and some distros may also apply patches to some of their library that breaks stuff too!
          often, with complex libraries, even when you check the version number, you may have behavioural differences between distros depending on the compile flags used (i.e. some features being disabled, etc.)
          so, while in theory portable builds work, for them to be practical, they most often are statically linked (all the dependencies get built into the executable - no relying on system libraries). and that comes with a huge size penalty, even when compared to flatpaks, as those do have some shared dependencies between flatpaks! you can for example request to depend on a specific version of the freedesktop SDK, which will provide you with a bunch of standard linux tools, and that’ll only get installed once for every package you have that uses it