Future plans for Software Center

Fatih19

hyphens Yeah, so you don't have to worry about selective updates.

hyphens

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>>>

hyphens

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.

yursan9

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.

hyphens

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.

JoshStrobl

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).

hyphens

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?

hyphens

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.

[deleted]

hyphens It doesn't get more empowering than this http://www.linuxfromscratch.org/

hyphens

[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!

yursan9

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

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.

dbarron

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.

kyrios

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.

hyphens

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 😅

Nycticorax

kyrios I am not sure why the notion of a rolling release model distribution keeps resurfacing in this discussion. If I have understood @hyphens's point correctly, rolling vs. non-rolling bears no relevance whatsoever. For the point is just to make it reasonably easy for Solus users to upgrade from system-required update candidates vs. non-system-required update candidates. This is what would allow users to choose between, in layman's term, upgrading kernel + desktop environment + essential librairies vs all that PLUS all the packages for various third-party programs which the users may have installed over the years (telegram, spotify, libreoffice, etc.)*

In short, insofar as I've correctly understood the claim, the claim is that the choice to upgrade from the Required / Security / Others categories currently represented in the Software Center should always be available to users from whatever piece of software is playing the role of the actual Software Center. Of course, perhaps the definition of these categories will change over time. As long as these categories are delineated in a way that allows users to keep an up-to-date working state of the Solus distro without wasting hard drive space and network bandwidth, it's ok, I suppose. But removing these categories, and the upgrade choices they underpin altogether, looks somehow preposterous. So what is the argument against this claim?

*: Unless the philosophy is to push all third-party packages to flatpaks or snaps? But I thought these always added overhead to their 'Solus native' counterparts?

Harvey

Nycticorax I am not sure why the notion of a rolling release model distribution keeps resurfacing in this discussion. If I have understood hyphens point correctly, rolling vs. non-rolling bears no relevance whatsoever.

So a guy who wants to keep the kernel because he likes the version number you take notice of. But Kyrios who actually works on Solus saying the fact that Solus is a rolling release matters and you ignore it...

IT MATTERS
IT MATTERS
IT MATTERS
IT MATTERS
IT MATTERS
IT MATTERS
IT MATTERS
IT MATTERS
IT MATTERS
IT MATTERS

JoshStrobl

While I appreciate everyone's remarks on this thread, I want to lay it to rest:

It is not technically feasible with the current package manager and Software Center (or even current package manager and new Software Center) to reliably ensure that package selection by users will result in the continued functioning of their system or applications.
The whole argument that "well I like an old version of xyz" is frankly irrelevant to any discussion on cherry picking updates. If you need older packages and a significantly slower software release cycle, Solus is not for you. We are a curated rolling release. We will update packages whenever it is necessary or appropriate, and we will hold back packages whenever it is necessary as well. We only support the latest release of that specific package and we expect users to use that release since it is what we support. Randomly going off the beaten path is not supported or advised.
Randomly holding back packages will make debugging any issue you have to be significantly harder. It is reasonably expected that you have an up-to-date system before reporting issues, or when validating issues. Not doing so means members of our community and the team are simply wasting time that could be better spent elsewhere.
The kernel is a fundamental part of the operating system. It's literally responsible for everything that isn't in userspace. As @kyrios stated, you are opening your door to problems like unpatched vulnerabilities, unexpected performance degradation (that you may just chalk up the be a separate underlying issue), etc. That should always be updated
While I understand the argument about limited bandwidth (I'm sorry but package upgrades aren't going to massively change your available disk space, let's not use that as an argument), that can be solved with package deltas, which only provide the files which have changed. There are improvements that are planned and will be made around this. Solving the issue a layer up in the Software Center by making updates selectable is not the correct way of solving this.

Solus is fundamentally a user-friendly consumer Linux operating system designed for home computing devices. Enabling for example, my mother, to be able to arbitrarily choose which updates to perform on her system, without her having remotely the right education and technical expertise to make that decision, is not okay. There is a reason why Windows Update does not arbitrarily let you pick and choose system updates. They might separate our Windows Defender security database updates from that, but those do not fundamentally change the operating system.

Putting update / package selection in the hands of average users is a mistake and it is one we intend to remedy in the Software Center. More technical users are always welcome to use the exclusion flags in eopkg, they are just doing so with the caveat that they should not expect support from us when doing so.

I'm not adding in the functionality into the Software Center just to appease Linux users, whom are sometimes more technically experienced. Traditional Linux users are not our target audience and they can already be appeased using eopkg features. Period.

« Previous Page