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]

    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