kyrios If the only option left to install 3rd party/proprietary apps in Solus would be snaps - then I am worried. I have tested a few snaps both in Solus and other distributions, and while it usually works great with some applications it is often broken or very inconsistent theming wise. The 3rd party handling is excellent as it is in Solus.

      If the only option left to install 3rd party/proprietary apps in Solus would be snaps - then I am worried.

      Nobody said that. Even the blog post states "Introduce support for Flatpak and Snaps via our planned plugin architecture". But we do plan on killing off the old system.

      tobcro The 3rd party handling is excellent as it is in Solus.

      I'm sorry but no, it really isn't. We have to manually update the pspec.xml and actions.py files (which are from the old build system) if a 3rd-party item is outdated. If an item is outdated and someone goes to install it via the Software Center, it will basically lock up the Software Center or provide an extremely cryptic message. It's not like our binary package repo where you can still install the current version even if it isn't up-to-date. These 3rd-Party applications do not automatically update or have a sane update mechanism (our "Check for Update" is actually just trying to fetch the pspec again and installing a newly generated eopkg), which is not the case for snaps (which periodically check for updates and update via their refresh mechanism and snapd).

      Building on that, in order to do this we have to interact with pisi directly, over python 2, which means essentially forcing ourselves to have that as the language for the Software Center, which results in (IMO) a less robust experience that also takes up more memory.

          tobcro My two cents identical to yours. My experience is snap clunky/risky awhile the maintained 3rd party page commands rocked. In other words terminal installation of 3P always worked much better for me than SoftwareCenter 3Party installation or snap. At least we still have it, maintenance mode and all.

          EDITED after re-reading Justin: patience. It all works out at the end.

            JoshStrobl I truly understand and have respect for the problems you are dealing with here. What I meant was that for me - as a user - the 3rd party handling in Software Center has been a great experience, especially compared with doing the same things in other distributions.

            And I withhold that snaps/flatpaks are not really there yet. This is not Solus fault. But if you somehow can work around it and make snaps (and/or flatpaks) work just as great for the user as the 3rd party section, then I am of course fine with it. As a user I dont care about the method, just the function and the result.

              I understand and support the reasoning behind deprecating the 3rd party repo, however I wonder whether we can "evolve" the legacy 3rd party repo's methods, as I prefer the idea behind it to Snaps and FlatPaks.
              Perhaps some of the enhancements brought by the the new trackers could be of use to such an endeavor, if someone would attempt it.

              however I wonder whether we can "evolve" the legacy 3rd party repo's methods, as I prefer the idea behind it to Snaps and FlatPaks.

              There is a way to evolve it. Drop 3rd-Party and encourage vendors to use Snaps or Flatpaks. Microsoft, Slack, GitKraken, etc. are already doing this with snaps. I don't think it is in our best interest to have a separate third-party mechanism.

              As a 3rd-party maintainer I wholeheartedly agree with Josh. It's using the ancient package format, the update mechanism is terribly inefficient and error-prone (with almost no real feedback), and things easily break, e.g. when there is the slightest change to a URL, or just a momentarily unavailable server.
              Integrating snaps/flatpaks would make everything simpler for both users and devs. Perhaps they are not a perfect solution (yet), but they're getting there.

              Out of curiosity, how will snaps and flatpaks be managed against apps already available in Software Centre?

              For example, if GIMP is available on all three platforms, would there be a way of highlighting the version in Software Centre as the first go to choice to install rather than installing from Snaps or Flatpak?

              I presume this would give the best experience as the version in Software Centre has been curated and known to work well in Solus?

              For example, if GIMP is available on all three platforms, would there be a way of highlighting the version in Software Centre as the first go to choice to install rather than installing from Snaps or Flatpak?

              If it exists in the repo, we won't show the respective snap or flatpak.

              What about if there's a flatpak AND a snap for an app? Will we be able to choose, will one be preferred over the other? This question is just about the presentation in the software center.

              Here are my speculations 😃

              I simply imagine there will be a priority between the different sources that will be defined by the core team for example:

              1. Shannon/Stable repository
              2. Snapcraft
              3. Flathub
                ...

              It makes no sense to focus on the package format because Solus is designed for everyone and a lamda user should just be able to easily find the application and install it without having to wonder what snaps, flatpaks, etc are. We could also imagine that in the future there would be alternate store to (for example) flathub also shipping flatpaks packages.... who knows ?

              There could be a visual for each source type (like the Solus, Snapcraft, Flathub logo) to identify from which repository the application comes from (and to know where issues should be reported in case of problem with a package) or something like that.

              23 days later

              Harvey But not everything is available. For example, Google Chrome Beta is not available in the Snapcraft Store, nor Flathub, while it is available in the Solus 3rd party repo.

                ugh.. going full snaps route? i still dont see native timidity for the featured openttd

                  • [deleted]

                  • Post #21

                  retrowertz No, where did you get that thought?

                    The goal is to fully deprecate 3rd-Party, however for specific applications like Chrome where there is neither an officially-supported flatpak nor a snap, those will use the current legacy system.

                      JoshStrobl
                      Getting rid of that devoted page will be heartbreaking (I've come to know it and love it) but I know you guys and girls are aiming at streamlining.
                      Will these 3rd party apps be transferred to the 3rd Party tab in Software Center? Or will these current things be exclusively Snap? Or undecided?
                      WIll they be maintained by you or independent of you? Or the way it is now: maintained but with the "install at your own risk" disclaimer you have in the SC?
                      So many questions, sorry!

                        1. Snaps and Flatpaks are likely going to be integrated into our existing category system, with an indication that it is a snap or flatpak, and not something that is from the repo (or a disclaimer along those lines). The same goes for any 3rd-Party applications (namely Chrome and its various channels), which will have appropriate disclaimers as well.
                        2. 3rd-Party is already maintained by us. We are not committed to providing any snaps or flatpaks, that is the responsibility of the software vendor / developer to do. If we're not allowed to redistribute it (we're explicitly permitted to do so with Discord, Teamspeak, Vivaldi to name a few) then the vendor has to provide it themselves.
                        3. Only very specific cases like Chrome will warrant the use of our legacy 3rd-Party repo, everything else will be removed. So the expectation would be for say, GitKraken, that you would install it via snap instead of 3rd-Party, or same with Spotify, and as such we would remove it from our legacy repo.
                          2 years later