New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: Forbid breaking the system #1
Conversation
Unless the system has a file at `/etc/apt/break-my-system`
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The thing that stands out most, is how lost that warning message is in the HUGE list of packages. It's not the 90s so can't we (eg) |
We're aiming to make further improvements over in https://github.com/pop-os/shop so users don't have to fall back to the terminal in the first place, but I don't see any reason (from a UX standpoint) why we wouldn't accept something like this if you'd like to open a PR for it. Upstream apt is located at https://salsa.debian.org/apt-team/apt if you'd like to work on it there instead/in addition. I'm not sure how much a red color would help beyond the already strongly-worded messaging, though. Some people will still proceed without understanding the consequences, which is why we no longer show the prompt by default. |
The strongly worded message will atleast be identifiable/discernible through the wall of text if it is coloured another colour. Maybe the colour could also make the warning not seem trivial. Given apt already colours trivial things like the progress bar, this will only improve the experience. |
I really don't think we should risk the possibility that they'll still continue to ignore it or think they can handle the consequences. I'm sure someone out there would go through with it. |
Would you guys mind adding something about this, or maybe a link to the forked APT repo on your Differences from Ubuntu page? I remember I once rendered a Pop_OS system non-booting because I installed a different kernel, then assumed I might similarly be a little perplexed to discover only through experimentation that Pop_OS is doing things like marking desktop meta-packages as essential instead of just tools like 2¢ about the message text and what's a sufficiently severe warning: I think the kind of extra gate you've added here, which doesn't require patching or replacing APT to get around it, but also doesn't invite the user to override it by telling them right there in the prompt what they can do next to override it, is a great compromise. |
I would hope that this is a change that Ubuntu and Debian alike would be willing to accept upstream, so it doesn't have to be a difference. |
I sure hope not. It's fine if you decide to take a hand-holding approach for users that clearly have a good reason not to use your GUI, but users that feel confident enough to use an OS where a CLI is actually supposed to be used should not be limited in their freedom to make impactful choices because some inexperienced Pop users aren't able to heed a warning and feel the need to go in against very clear warnings. Edit: |
There is still a way to override it. And this is the behavior that every other package manager has. So I don't think it's the wrong thing to do. |
Sure, but we're talking about Arch. A system that essentially has nothing but a super minimal image on a terminal on first boot. |
Does that mean it's any less of a Linux distro? Or that Pacman is not a package manager? |
This is just cherry picking to make a point that I'm sure you know I just don't agree with. RPM distributions like Fedora don't allow this. If it works for them, it should be good enough for Debian. |
It's not limiting your freedom if you can override it, is it? This is just about making it more difficult for a newcomer (or even someone just not paying attention) accidentally wrecking their system and having a bad impression of the Linux desktop. I don't think we should be promoting that kind of experience. |
Except this does limit user freedom because the only way to get it working is an undocumented file that needs to exist somewhere, without which users can't even go and set up a different DE! And if you'd keep this contained to just Pop, I wouldn't even mind. But no, there is now a suggestion to try and merge this hackjob fix upstream, making it affect other distros too. All because someone on YouTube tried to install Steam and that caused conflicts and breakage. |
Working on upstreaming in https://salsa.debian.org/apt-team/apt/-/merge_requests/196 |
Maybe it should be command line parameter such as File exist solution might cause problems if disk is having some issues (corruption, mounted ro, ..) and you might be in recovery mode and you might not be able to create or delete said file. |
At this point it's up to Debian's apt maintainer to make the choice. Hopefully we can do something good here for everyone. |
The recommendations from the Debian maintainer seem like cleaner changes to achieve the same effect. |
Just to understand: Weird dependencies with steam are bricking the system. Instead of trying to fix the dependencies (that basically uninstall the desktop env) this tries to make it even harder to break the system? Or did I miss something? If yes can someone please point me to the issue fixing the dependencies on the It just sounds like: Instead of trying to fix the actual problem/issue only the symptom is being addressed. Also while making it harder to brick your system is generally a good idea - not telling the user upfront how to do it anyway if you know what you are doing also seems like an exceptionally bad idea. :-( Edit: Removed diff as the Debian Maintainer made similar recommendations. |
That is not the case.
There was never an issue with the Steam package. The issue was with the 32-bit binaries for some dependencies of Steam not being built properly for a short period of time. From my understanding, when Steam went to install the 32-bit binaries while they were not available from the Pop!_OS PPA, it fell back to the versions Ubuntu had available, which also (correctly) tried to install the matching Ubuntu versions of the 64-bit binaries. This caused system components that wanted the Pop!_OS versions to get removed, including pop-desktop. The first "fix" was getting a build server to successfully build those 32-bit binaries again; I'm not the one who did that, but I don't think it would have involved a GitHub issue page as it wasn't an issue with the code. Even after the relevant builds were fixed, users could still run into the issue if they attempted to install Steam without installing system updates first. The second "fix" for this was releasing an updated iso to remove the "install updates" step for new installations, which was done a week ago. The third "fix" in case a similar issue occurs again in the future is to ensure that users know to try installing updates if an application fails to install. The Pop!_Shop is being updated to add a more user-friendly message and button to install updates: see pop-os/shop#296 and pop-os/shop#302. QA procedures have been adjusted to increase the reliability of Steam going forward. Humans already checked Steam manually before every mesa update; humans now also check Steam manually before every systemd update. Steam is also tested before new isos are released (although in this case, I don't believe this would have been an issue in the "bad" iso until the updates related to the failed i386 builds were published later.) Additionally, work is being done on automated testing via openQA to catch issues faster than humans, especially when issues may be influenced by packages coming from upstream Ubuntu that do not go through Pop!_OS QA. This apt patch was a low-hanging fix intended as just one line of defense against future breakages. I hope this alleviates your concerns about the actual problem not being addressed. |
Thank you very much for the explanation. :-)
Yes it does. |
I really have no reason to comment here, as I don't really use any of the distributions in place, but regardless: I disagree with Debian and Ubuntu having this no-break-policy by default, yet I do understand some people willing to have it. My proposal would be to have a configuration file for apt at Arbitrarily just having a file to set a configuration setting seems arbitrary, and I'm not entirely certain if it follows any particular standard. |
Where is it documented that creating |
I appreciate that you solved this problem yourself :) For other people, note that as of this writing, the top hit on Google is a StackExchange post, posted almost exactly when you made this comment, made by "Joseph Sible-Reinstate Monica" which I'm just going to assume is the same person as josephcsible. This honestly feels like the right solution; anyone unable to do a Google search for the exact error message really should not be bypassing the error message, but if you do that search, there's instructions right there (along with a rightfully terrifying filename.) |
Yes, that was me. But I think this information should be available in our first-party documentation somewhere instead of people having to rely on third-party sites for it. |
Some suggestions:
|
Automated GUI testing is a very good move. Thanks for your work! |
That stuff (removing the UI with apt) even happened to two friends of mine that are using Linux since years. One for more than 10 and has done Debian packaging. So it's good to try to have more foolproof software. |
I have got a question about this topic. I tried the solution of putting the break-my-system file in /etc/apt, but somehow I still do not get the option to type "Yes, do as I say" when trying to remove essential packages. Is there a new way of circumventing the linus-proof? |
Yes, this quick-and-dirty fix was replaced with a solution in upstream apt: #4 The upstream merge requests were:
The new way to get around the safety is by passing the (There is no longer a "do as I say" prompt, as that was shown to be ineffective. Passing this option will simply show a warning and give you the usual |
Also, note that we currently ship Ubuntu's apt package in 22.04, so this GitHub repository does not reflect anything happening in Pop!_OS 22.04 right now. The only branches here end in |
Thanks that worked :D |
Unless the system has a certain file in place