I was told by a core team member (according to this forum), that there are plans to disable the ability to selectively upgrade groups of packages (like security upgrades only) in the upcoming versions of Solus-SC.
Effectively making it harder to do updates in anything but an all-or-nothing fashion.
Are those plans in motion?
And will those plans affect eopkg's cli options?
It would be unfortunate if both answers to those questions are 'yes'.
It's going to a little later on. But, I think the team will only disable selective upgrade from the SC, so casual user won't be able to shoot their own foot by cherry picking the updates. Cherry picking update is useful for debugging reason, so the CLI will still provides the function. CMIIW
There are currently no plans in motion regarding the Software Center, the focus at this moment in time is validating the GNOME 3.32 Stack Upgrade. When the Software Center is rewritten however, the option to selectively upgrade packages will likely be removed, as currently with eopkg it has proven to be problematic and is more likely to lead to a broken system.
There has been no discussions whether this is something that will be changed in sol (no changes are being made to eopkg). So I can't really comment on that yet. In all likelihood it'll stay in sol.
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.
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.
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.
hyphens It doesn't get more empowering than this http://www.linuxfromscratch.org/
[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.
