hyphens He said it will probably still exists in sol and we'll be switching to sol in the Budgie 11 release.
Is there any use of eopkg when sol is released?

    yursan9 AFAIK selective upgrades are not as easily done on eopkg.
    When I wanna do that I tend to favour SC for how easily it lets me do it. I'll be content and happy with the CLI tool if I have to, but I can't help but feel a bit threatened. If this was removed from SC what is to assure me that it won't be removed from the CLI tool later on? I have really high hopes for Sol in all honesty. And I hope as much the SC may be abstracted, more options will be added to the CLI package manager regardless.

    It doesn't help my worries at all that a Solus core team member says "I really wish there was no way to not upgrade all packages. Just all or nothing. Selectively upgrading is a huge mistake and a cause of MANY broken systems." Those wishes sometimes indicate what's going on in the development team's heads. And it can be really worrying.

    hyphens Your example about firefox is kinda...wrong, I guess? Who will maintain the non-quantum package if people never update to newer release? Also if Solus keep all old version of package, the server will not keep up.

      JoshStrobl In all likelihood it'll stay in sol

      this is good news. I hope you all see it through. Still, wouldn't it be better to hide instead of remove that feature in the SC? It's in my previous reply>>>

      yursan9 It's not the maintainer's job to keep every version of the package history. That is far beyond what's needed for a working repo. And it's also not what I'm trying to ask for with the firefox example.
      The example assumes you already have an older versrion of FF installed locally. You just don't want to upgrade it. It's your side of the deal not the maintainer's. They'd be upgrading the packages normally but you will be opting not to install those upgrades.

        hyphens And what about the security? Old version of browser can be easily use as attack vector.

        I guess you'll just need to wait and see. If Solus is going to starts the development of the new SC or sol, there will be discussion on irc, github, or this forum. We just need to be an active contributor by pitching idea, code, and design.

          Except the problem arises when an end user thinks they know better to hold back a package than the individual which pushed it in the first place. They may be holding it back when there is a stack upgrade, and suddenly that package no longer works.

          I'm sorry but the concept that you can cherry-pick updates in the new Software Center is not up for debate. I've been with the project for years and the option to allow cherry-picking in the Software Center was a mistake to begin with. It was going to be removed with the original rewrite by Ikey, and it'll be removed by me when I rewrite the Software Center to C. It's always been problematic and there is literally no chance of it being fixed until we have a more competent package manager.

          When that is the case, we may be open to adding the support back in and force upgrading excluded packages when we (maintainers) simply know better (like during stack upgrades).

            JoshStrobl I don't think it's about who knows better. It's never been about that.
            It's simply the fact that a packager is absolutely unable to take in count every single system combination and every single use case, while on the other end the user is the one being exposed to those use cases. Sometimes an upgrade may be the more obvious thing to do, but the user doesn't like the direction the program's upstream is taking, and there are no good forks. a package not working due to an upgrade is as much of an edge-case (if not more even) than this kind of users I think.

            Offering sane defaults then empowering users to take responsibility and more control should then at least be an opt-in option.
            It may be preference or legit reasons, but shouldn't the user be the one taking responsibility for their own system?

              JoshStrobl Well, since it's not up for debate, best I can hope for is for the CLI tools to assume I'm familiar with the OS enough to know how to use a CLI, and let me use those features still. That's what I'm looking forward to in Sol at this point.

              yursan9 this point seems valid enough to me, security I mean, but aren't there older versions of those packages in LTS-model systems? If they're officially provided there, it makes sense that they have no security flaws. Feature upgrades != security upgrades after all.

                [deleted] ah yes, the "if you don't like it do it yourself" argument.
                Thing is, I like Solus. This is by far not a dealbreaker. There are many workarounds. I don't want to recompile everything. I also don't have the time to. I like being on the bleeding edge with many packages and I like eopkg's interface and option structure way more than all the other package managers I dealt with. And I love the component categorization of the software center. LFS or Gentoo aren't good enough trade-offs imo. If you wanna do it gl;hf. I don't.

                This is not the point from this discussion. The point is requesting control to be available (even as an opt-in option with --yes-I-want-to-destroy-my-system or a big red checkbox), instead of disabling it entirely for the sake of abstraction!

                  For Pete's sake, if you want to hoard old libraries and binaries, just install them outside the packaging system (from tars or source code) and expect no support on your witch's brew of mixed linkages. If you really know better, then do what you want, just don't ask other people to solve your likely problems.
                  I fully understand the developers philosophy for everything to be linked with the current libraries, otherwise, 'there be dragons' (as the old explorers maps showed on the boundaries). This is the typical stable, supportable view.

                    dbarron

                    hyphens ah yes, the "if you don't like it do it yourself" argument.

                    I'm really being misunderstood a lot today apparently. I'm not asking for my mixed package system to be supported, that's a stupid thing to ask for. And I'm not saying I know better. Hell I'm not even interested in holding libraries. I am very aware of the stability concerns that stem from holding packages.
                    You may consider my hoarding tendencies weird, but I really like the version number 4.20, and my motivation is absolutely nothing in comparison to more legit needs to hold on packages, at least temporarily.

                    I'm all with voicing it clearly; "If you go here, don't expect support from us", and all I'm preaching is to leave me your nice tool to do it instead of making me reinvent the wheel with my own source management system.
                    I do like the tooling offered right now. I'm asking for more control, yes, but I'm not disregarding what's already offered as useless. It's just worried of being deprived of the control I have.
                    Offering the option where it makes no sense isn't an absurd new thing I'm asking for! Many tools you're using do just that. starting from the most basic ones like rm's --no-preserve-root to the more complex ones like firefox's about:config (which can and does break webpages)

                    again, I'm happy with a CLI tool that does this, but I was just a believer that Solus is one of those systems which hopefully will make it possible to manage most things with a GUI, minimizing the reliance on a terminal. (and the complexity it brings in doing tasks that a GUI can do with the click of a checkbox).
                    I may be wrong about this, but hey, if it really is one of the end goals, simplifying things by disabling control will take away from that.

                      I gotta go so I'm gonna wrap my discussions and leave the rest to y'all

                      • Looking forward to Sol. hopefully it answers all my concerns
                      • I understand that SC's current way of holding packages has many limitations due to eopkg.. I just hope that doesn't make the feature off the table
                      • I just want to be allowed to check a big red box that lets me reduce the stability of my own system as a trade-off to a feature I want -- all in my own responsibility.
                      • I'm offering an alternative; to hide the bad options in an advanced opt-in menu instead of leaving them in the open or completely destroying them 😅

                      hyphens In fixed release distro, like Debian or Ubuntu, old version of software is maintain by backporting security patch. In rolling release distro, who will do that? Especially when it's easier to upgrade the packages

                      hyphens but I really like the version number 4.20

                      The first quetion you should ask yourself is why did you choose a rolling release model distribution if you don't want to roll, especially for a key component like the kernel - I assume this is what you're talking about, since you did only mention the version without the name; meaning you already broke something 😛

                      This way of randomly cherry picking packages from the repository is problematic and leads to breakage even for the advanced users who "know" what they are doing. You have no idea how many time problems were reported because of this.

                      This may eventually be done on a fixed point release, especially if it's a LTS version, but it is totally inappropriate on a rolling release where components are constantely updated. And if by luck there are no immediate breakages, it will open doors to other problems like unpatched vulnerabilities & co.