HolySoap This was discussed on the dev tracker and on IRC. This package hasn't seen a release in almost 3 years which could eventually put your computer at a risk and it also relies on old/unsupported technologies that should be outphased to allow future updates.
Where did youtube-dlG go?
kyrios I get that it's old and potentially a security threat(VERY unlikely), but that doesn't excuse the fact that you(the DEV team) discuss and make these decisions on a obscure and niche platform(IRC) and then are suprised when people are not happy about the decisions you made without even a proper annoucement it would happen. I love Solus(mostly Budgie), but these kinds of actions really make me question the future of the distro and if my future self will continue too use it.
Xrey274 IRC is hardly obscure or niche. It's very common in Linux and open-source communities. That said, this was discussed in the open on our bug tracker as pointed out by @kyrios. So it's not as though we didn't discuss this in a more approachable medium. Security aside, if this package were not in the repo today and someone requested it be added, we would outright reject it for being unmaintained. It's not required for anything else that is maintained to continue to function, so it was not given a free pass. I understand these removals seem random at times. It takes too long to individually audit 4000+ packages to see which ones have gone dead. As a result, these kinds of ad-hoc removals do happen when we notice or someone points them out.
- Edited
Video Downloader is a flatpak program (flathub repo) that does a lot of the same thing, although not near as well or as thoroughly as youtube-dlg. I too love that program and wish it were still available. When Python 3 arrived on the scene, it's days were numbered.
I felt the same way about Gtapecalc when it went to mothballs. Maybe somebody will take these two programs up and bring them current again.
DataDrake I am not disagreeing on the decision of removing these packages, that's fine. My problem is that it's not made obvious to the average(or even sometimes advanced) Linux user why and how their program disappeared overnight. IRC IS NOT the first, second or even third platform any newbie will try to check when having such a problem and that's assuming that they even know what IRC is. My point is: When doing these kinds of things try to be as vocal as possible about them, you have a blog and forums - make posts about it and pin it for at lest a good month or two before actually doing it. Just my $0.02.
Xrey274 We've made announcements in the past and plastered them all over every public space we have and a large number of people still manage to miss them. I'm also not really sure what those kinds of posts end up accomplishing. Sure, users will be informed of their intended removal, but inevitably it will turn into a series of emotional appeals from a vocal minority about how important XYZ package is to their workflow, isn't doing any harm, etc. But at that point we have already made a decision and aren't going to reverse it. We do make RFC announcements on the bug tracker when a package only needs a new maintainer. Someone has 30 days to see and chime in on those Tasks to volunteer as the new maintainer.
- Edited
First of all, the devs do a great job filtering out unmaintained packages and keeping the repo clean and modern. I don't think that's the issue. The issue HolySoap is bringing up isn't about the package removal debate process. It's about life instability caused by auto-removing user installed apps without any graphical warning just because they have been removed from the repo. No other rolling release (or otherwise) distro does this and for good reason, and extremely tiny security risks don't justify stripping users of control over their own computers.
It should be sufficient to remove packages from the repo and then announce to users that they should uninstall unsupported apps & refuse to answer support questions about unsupported apps. That's all. There is just no good reason to go one step further and auto-uninstall things no longer in the repo. There are many good reasons not to auto-uninstall things, not the least of which is that each time this happens the forums are going to be peppered with genuinely confused and frustrated users forever.
Example from my own experience to illustrate the point: I use Solus as my daily driver. I made a work presentation via Spice-Up. I updated via Software Center before bed. No warnings, everything looks OK. I go to work the next day, and my presentation app is mysteriously gone -- auto-removed without my knowledge or consent. This is not how computers are supposed to work, nor should it be users' responsibility to read every news post to make sure their favorite apps aren't going to be randomly uninstalled. As you say, DataDrake, you want to avoid emotional appeals and keep the repo secure (we all agree with this), so just don't auto-uninstall apps and nobody will care anymore because it then puts the onus on users to maintain security instead of the devs having to take responsibility over administering thousands of random use cases and dealing with after-the-fact complaints.
I encourage HolySoap to start another thread about this overall issue, rather than shoehorn it into this YoutTube-dl-specific thread in order to get a clear read on how many users have been negatively affected by this unnecessary design policy. I think it should change and it's a minor change.
JohannPopper It's about life instability caused by auto-removing user installed apps without any graphical warning
This is a known issue with the SC and will eventually get corrected. Discussing it further won't change that or speed up the process. eopkg actually does warn you about this, just not gracefully either. I will be addressing this in sol, but again, not something getting fixed any time soon.
JohannPopper It should be sufficient to remove packages from the repo and then announce to users that they should uninstall unsupported apps & refuse to answer support questions about unsupported apps. That's all. There is just no good reason to go one step further and auto-uninstall things no longer in the repo.
I wholeheartedly disagree.
eopkgonly has one method of deprecating packages. Marking a package as Obsolete is used both for removing packages that are 100% no longer needed and people will not notice them missing and for removing things that we are removing from the repos for other reasons. There is no way to distinguish the two or even report them differently.- When something is no longer needed it always should be removed. This is why Obsoletes are not optional removals and should be treated as such. Leaving those packages around may interfere with other packages that we are adding as replacements or open you up to potential security problems. Neither of those is acceptable.
eopkghas no mechanism to report to a user that a package has been removed from the repo, while still allowing that package to remain installed. This means a user could go months or even years before that package finally breaks or they reinstall and notice. That kind of silent breakage is something we can't endorse either.- In light of 1 and 3, when we remove things from the repo, removing them from your system is far more logical letting you continue to go on oblivious to this change.
I understand that the lack of visibility is frustrating and I'm not suggesting that shouldn't be improved. But in light of the limitations of eopkg and the existing SC, this is the only approach that we can take.
JohannPopper I encourage HolySoap to start another thread about this overall issue
Full stop. Continuing to drag this on further will not improve the situation. None of this can be fixed until either the SC is patched or the SC is rewritren and eopkg is replaced. If you are so passionate about this problem, stop complaining and go fix it. No change to the workflow of a graphical application is a minor change. It's a royal PITA. Don't diminish it by treating this like some small change to policy.
And for the last time. This isn't debate club. Throwing a wall of text at me or arguing with me all day isn't going to change my mind. All you are doing is pissing me off and taking time away from the other things I need to be working on to even have the time to start fixing these problems. I am being extremely patient with you right now. Stop trying to escalate things like this or I will have no choice but to ban you.
DataDrake "This is a known issue with the SC and will eventually get corrected."
Cool. Didn't know that. That's all that's necessary. Thanks & good luck.
"#1-4"
Fair points that demolish my argument.
" If you are so passionate about this problem, stop complaining and go fix it. No change to the workflow of a graphical application is a minor change. It's a royal PITA. Don't diminish it by treating this like some small change to policy."
I'm discussing, not complaining. I didn't suggest any change to the SC GUI because I know it's not easy. I was under the reasonable but incorrect assumption that auto-removal was a hidden eopkg policy setting as opposed to a baked in obsolescence feature. Now we know.
"And for the last time. This isn't debate club. Throwing a wall of text at me or arguing with me all day isn't going to change my mind. All you are doing is pissing me off and taking time away from the other things I need to be working on to even have the time to start fixing these problems. I am being extremely patient with you right now. Stop trying to escalate things like this or I will have no choice but to ban you."
I'm just trying to be helpful. I thought organizing support threads for common issues on the forums would centralize info in the place most users look first when they run into problems, like what you've shared with us in this thread about the way eopkg works, not put pressure on you guys or escalate negativity. I'm out.
