Edward78 While I have no doubt that at some point in the distant future Josh and I will decide to develop something like YaST, we wouldn't just use it in Solus:

  1. It's too integrated into (Open)SuSE's implementation and packaging. We wouldn't want to be forced to adopt their toolchain or heavily patch it to support ours.
  2. We wouldn't adopt something that is so core to the Solus experience, with its future in the hands of an upstream project. This is the same reason we don't use existing package managers (CLI, TUI, GUI), packaging tools, or installers.

      George Nope. usysconf is mostly post-install triggers at the moment. It deals with "stateful" configuration through execution of external commands, as opposed to "stateless" configuration which relies mostly on configuration files.

        putzerstammer Thank you for the kind words. I agree that our Software Center was a good start, but there are countless improvements that should and need to be made to it, that we'll be excited to facilitate with a rewrite alongside the new package manager.

            I mean the configuration part of YaST, the install/package sys of Solus is great, The config part of YaST seems to have a tool for everything & it is not hard to change things.

            I think we have different opinions on YaST. To me, it's a complete mess and the amount of configuration it provides would overwhelm almost every user, with options they're never likely to use and have no reason to be exposed via a GUI.

              JoshStrobl count me another non-fan. while testing distro xxx, yast was shiny redunancy since system settings did the same thing. So despite Sudo, system settings either over-ruled Yast or Yast would over-ride system settings. messy,

                George Kinda off-topic, but yes, sol will be able to manage .eopkg archives. eopkg uses XZ compression. We have not revealed any of our plans regarding a new package format following the initial eopkg-compatible implementation of sol.

                    DataDrake wow, I thought that the updated eopkg is needed for zstd decompression enable as arch did, considering all of the above, I then do not understand why rewrite eopkg

                        George
                        Well

                        1. It's written in python2 which is EOL. So it needs to move to another language regardless
                        2. It has some legacy code it inherited that Solus does not use (its fork of pisi)
                        3. Old build system code that Solus no longer uses outside of packages for the third party system an when that moves moves to ypkg. Will not be used at all.
                        4. eopkg does not handle timeouts well, which Josh tried to improve but can not fix entirely due to the way a tool it uses returns a time out as success
                        5. Being written in python means if python breaks your package manager will break (sol will not be written in python3)

                        Aka eopkg is shit.

                            George Who rewrites a package manager just to change a compression codec? It's just a format change and a well-designed package manager handles this just fine. Even eopkg could be pretty reasonably modified to support zstd compression, but that's hardly the only thing I would want to fix in a rewrite. The list is so long that it's easier to burn it to the ground and start fresh. @Harvey has a pretty good summary of the main points that most interested people would care about.

                              12 days later

                              JoshStrobl Well ya that is a good point, it prob. will overwhelm most users. Mostly I like the boot manager, a 100% GUI for all settings.

                                Harvey

                                Being written in python means if python breaks your package manager will break (sol will not be written in python3)

                                Which language then?