I was hoping that the newer versions of Solus-SC will offer more control over which packages to upgrade, not the other way around. It seems counterintuitive.
If abstracting complexity and offering sane unbreakable defaults is the goal, offering "Advanced options (use this if you know what you're doing)" instead of completely disabling it makes more sense. I can understand how casual users may do something they don't know and end up 'breaking the system', but I feel like the percentile of users who'd do this, and the percentage of broken systems resulting from that, are dwarfed by the number of users who'd rather have that control laying around somewhere.
In most cases, those hypothetical very uninvolved users this decision would cater to, simply would upgrade the packages automatically without bothering to check/uncheck boxes of package names they may not know what to do with. Maybe even empowering them with good documentation to be more aware of their system if they felt the need to, by offering help to the frontline of the interface, would be a better thing to do in the long run I think.
I read a few suggestions about further-dividing packages into groups (like GUI applications, system packages, libraries, etc..) when upgrading. Pushing the more user-interfacing more isolated and more non-essential packages to the front of the list, like GIMP. And allowing users to safely make choices about what to hold from upgrading, instead of accidentally disabling an essential shared library or a system/DE core package.
Offering advanced granular options will surely show faith in the userbase's ability to take responsibility of their system and make judgements. And there are legitimate use-cases for wanting to only do security-upgrades for example. e.g. Keeping secure on a metered connection (say while travelling). It's not just about developers.
Heck, I was surprised to know that there's no real way to mark-freeze packages / dependency trees in eopkg.
This kind of thing makes a user who wants to have more control over their system feel shackled by the manual labour they have to do for such simple tasks. Even risking more system breakage by substituting this behaviour with eopkg up [-x | --exclude-from]
What if I don't like FireFox quantum and want to use a XUL-supporting version? What if I like the Linux Kernel 4.20 version number and upgrading to 5.0.7 won't bring me any real benefits? Newer versions of software aren't always better, and sometimes newer versions introduce unwanted behaviours.
In this case, I'm really hoping this post shakes up a discussion about the less immediate goals of Solus development; maybe even exploring the thin line between offering peace of mind with sane defaults, and babying the userbase like they can't use a good package management UI. To, ya know, manage packages. Not just bulk-upgrade them.
Hopefully we all come out of it with the best output. There is a parallel discussion going on GitHub as well that stemmed from the same discussion in one of the community's unofficial channels.
