Yes, Do As I Say II: The Yessening

[finest feck fips]

The latest release of Ubuntu (incidentally an LTS release) is currently affected by exactly the same kind of dependency issue as Linus Sebastian encountered in Pop_OS some months ago.

 

On a freshly installed system which has not yet been updated, trying to install an unlucky package produces a dependency conflict that APT offers to solve for the user by uninstalling their desktop environment.

 

(In this case, I think Ubuntu actually doesn't even make the user type the infamous warning message, since it doesn't mark the ubuntu-desktop meta-package as essential.)

[Ralphred]

So, even ubuntu are admitting gnome is a virus?

[Sauron]

even the site you linked says that it's being fixed... you know, sometimes people can make mistakes. do note that even if it doesn't display the ominous do as I say message it would still give you a list of exactly what will be uninstalled. before I get a "but this couldn't happen on windows"... that's a non-argument because windows doesn't have automated dependency management, nor does it treat the desktop as a package which would allow you to choose a different one. if you don't want this kind of problem on Linux just use static binaries or flatpak.

[shadow_ray]

Who needs a desktop environment anyways?

[finest feck fips]

On 7/24/2022 at 4:38 AM, Sauron said:

even the site you linked says that it's being fixed... you know, sometimes people can make mistakes. do note that even if it doesn't display the ominous do as I say message it would still give you a list of exactly what will be uninstalled. before I get a "but this couldn't happen on windows"... that's a non-argument because windows doesn't have automated dependency management, nor does it treat the desktop as a package which would allow you to choose a different one. if you don't want this kind of problem on Linux just use static binaries or flatpak.

Sure. The points that may be of interest here, reiterated from discussions of what happened to Linus during the Linux challenge, is that

 

1. This isn't really about a problem with Pop_OS, per se.

 

2. When you use the system package manager, you are operating on your entire system as an interconnected whole.

 

3. The expectation with Unix and Linux tools is that when a user requests something, the system is expected to make it happen, whatever that takes. In the case of package managers, that means computing and then offering various changes that meet the requirements given by the user/administrator, and expecting the user/administrator to evaluate the tradeoffs involved in those solutions.

 

It vindicates the decisions by distribution developers to explore new systems that steer end users away from the system package manager and toward containerized or bundle-based app deployment, when their goal is to accommodate 'power users' who are either new to the concept of systemwide package management or prefer a BSD-style separation between app installation and operating system deployment.

 

Users who are accustomed to administering their systems via package management (people like you and me) often prefer to avoid containerized/bundled systems like that (Snap, AppImage, Flatpak) for perfectly good reasons (e..g., disk use, platform immaturity, load times, ease of OS customization, as-of-yet-unresolved sandboxing quirks, etc.). But Windows and macOS users unaccustomed to having to consider (2) and (3) will likely prefer those systems that use an immutable base system and lock things down in various other ways in order to eliminate footguns.

[Ralphred]

3 hours ago, finest feck fips said:

in various other ways in order to eliminate footguns.

If the userbase doesn't understand they can literally uninstall their OS with a package manager, then it's time for the managers to have a "system" set of installed packages that throw some errors/warning if you try to uninstall them, but that's down to distro devs as to what gets flagged and what doesn't. But TBH there should be a "my permanent software" set too, so you don't uninstall that killer productivity program you use every working day.

The elitist jerk half of my brain is just repeating "LMAO @muppets" though...

[10leej]

47 minutes ago, Ralphred said:

then it's time for the managers to have a "system" set of installed packages that throw some errors/warning if you try to uninstall them,

they already do, their called meta packages. The problem is that apt does not treat metapackages in a protected status like pacman, rpm does.

[finest feck fips]

16 hours ago, Ralphred said:

If the userbase doesn't understand they can literally uninstall their OS with a package manager, then it's time for the managers to have a "system" set of installed packages that throw some errors/warning if you try to uninstall them, but that's down to distro devs as to what gets flagged and what doesn't. But TBH there should be a "my permanent software" set too, so you don't uninstall that killer productivity program you use every working day.

The elitist jerk half of my brain is just repeating "LMAO @muppets" though...

They do, and they have for many, many years. In Ubuntu's case, the packages which users are warned about when they attempt to uninstall them are those whose uninstallation would render the package manager inoperable.

But there has been some debate going back to the first incident about whether such warnings are sufficient. And clearly, for some users, they are not effective.
 

15 hours ago, 10leej said:

they already do, their called meta packages. The problem is that apt does not treat metapackages in a protected status like pacman, rpm does.

This is not accurate, neither with respect to what meta-packages are nor with respect to how pacman treats them. Meta-packages are just packages, themselves containing no files to install, whose sole function is to pull in other packages by declaring those others as dependencies. Whether something is a meta-package and whether or not it is somehow ‘protected’ from uninstallation are completely orthogonal.

Moreover, comparing RPM to APT is a category error— each tool sits at a different layer in its respective package management stack. APT is comparable to other high-level package management tools, like Zypper, YUM, and DNF. The counterpart of the rpm program in the Debian-based world is dpkg, not APT.