We should also change gnome-software to hardcode a select list of nonremovable apps and no longer allow individual applications to decide for themselves whether they are nonremovable. And remove CompulsoryForDestkop from upstream metainfo files.

We should also change gnome-software to hardcode a select list of nonremovable apps and no longer allow individual applications to decide for themselves whether they are nonremovable.

What's the rationale for that? Is this some kind of basic/advanced desktop mode? (Yuck.)

I don't really like adding special logic to gnome-software. In my experience, it just creates pain, as well as confusion. Well designed systems are transparent, all the way down.

And remove CompulsoryForDestkop from upstream metainfo files.

+1

What's the rationale for that? Is this some kind of basic/advanced desktop mode? (Yuck.)

Sorry, I was thinking that would be the alternative to removing CompulsoryForDesktop from upstream metainfo files, but I know you don't want to have any enforcement at the gnome-software level, so we can just remove CompulsoryForDesktop and not replace it with anything I suppose.

There seemed to be a consensus that we ought to have a small number of essential non-removable apps, including gnome-control-center, gnome-software, gnome-terminal and yelp.

We can block removing these at the gnome-software level. These would be too controversial to block at the dnf level. We see a very high number of complaints about gnome-software and cannot plausibly prevent users from removing it; they will switch to other distros over that issue alone. Honestly, blocking users from using dnf to install gnome-software would severely damage our reputation: we don't want to go there. Same for gnome-terminal and nautilus, since many users replace these with tilex, nemo, etc.

At the dnf level, we should block removing gnome-shell. That will, in turn, block removing a bunch of other core packages, including gnome-control-center. Since you don't want any differences between what we block in gnome-software and dnf, that suggests the rest remain removable.

We should also change gnome-software to hardcode a select list of nonremovable apps and no longer allow individual applications to decide for themselves whether they are nonremovable.

What's the rationale for that? Is this some kind of basic/advanced desktop mode? (Yuck.)
I don't really like adding special logic to gnome-software. In my experience, it just creates pain, as well as confusion. Well designed systems are transparent, all the way down.

I think the rationale is that it puts the list of essential components into a single place, so we can actually maintain it, as opposed to being spread across dozens of appstream files that are maintained by upstreams according to their own whims.

I think the rationale is that it puts the list of essential components into a single place, so we can actually maintain it, as opposed to being spread across dozens of appstream files that are maintained by upstreams according to their own whims.

Sure, I understand that, and what's being proposed is better than what we currently have. But that's not what I'm asking - what I'm asking is, why should Software have its own set of non-removable apps at all?

There seemed to be a consensus that we ought to have a small number of essential non-removable apps, including gnome-control-center, gnome-software, gnome-terminal and yelp.

These would be too controversial to block at the dnf level.

Well, that's what I thought the WG agreed yesterday. My own perspective is that Software is a fundamental part of the system design.

We see a very high number of complaints about gnome-software and cannot plausibly prevent users from removing it; they will switch to other distros over that issue alone. Honestly, blocking users from using dnf to install gnome-software would severely damage our reputation: we don't want to go there. Same for gnome-terminal and nautilus, since many users replace these with tilex, nemo, etc.

These observations are news to me, and they go against the evidence I've seen when doing my own user research. It's hard to wrestle with these kinds of questions without having quantitative data, but knowing a bit more about what's been observed would be useful.

FWIW I intended my agreement for making those few apps nonremovable in GNOME Software. A dnf-level list of nonremovable software is much more controversial. My suggestion remains to make only gnome-shell nonremovable.

These observations are news to me, and they go against the evidence I've seen when doing my own user research. It's hard to wrestle with these kinds of questions without having quantitative data, but knowing a bit more about what's been observed would be useful.

Without quantitative data, all I can offer are anecdotes. For starters, on basically every reddit thread about gnome-software (which is almost always a user asking for help with some bug), the top response is almost always "uninstall it and use dnf." This has been popular advice for a long time. I know that's not what we want, but it's not going to change anytime soon because we don't currently have resources to deal with the gnome-software issue tracker. Also, some minority of users will always reject a "package manager" that doesn't expose low-level package details. It's not an essential component of the system; we don't really want to encourage it to be removed, but nothing is going to break asides from automatic updates, and anyone using dnf to remove gnome-software ought to be well aware of that.

tilex has a much smaller, but vocal, following among users who like GNOME 3 design patterns and/or tiling. It looked like a modern GNOME 3 app long before gnome-terminal did, and it tiles. I've never tried it, but I guess that's basically it.

As for nemo... some people just don't like nautilus.

All these components are completely replaceable, and there's no negative effect on the system if they are replaced with capable alternatives. I see very low value in blocking their removal. If we're going to antagonize users by completely blocking them from doing what they want to do, we should have some big value reason to do so.

FWIW I intended my agreement for making those few apps nonremovable in GNOME Software. A dnf-level list of nonremovable software is much more controversial. My suggestion remains to make only gnome-shell nonremovable.

I think only making gnome-shell non-removable makes sense. This automatically makes gnome-control-center non-removable as well because gnome-shell has a hard dep on gnome-control-center.

And that's really the core what we need to protect.

every reddit thread about gnome-software (which is almost always a user asking for help with some bug), the top response is almost always "uninstall it and use dnf."

It's a bit hard to read user behaviour from a Reddit comment... but either way, my response to that is that we should fix gnome-software. If the system is so broken that users want to remove key components, we have bigger problems than someone not being able to do dnf remove gnome-software.

I'd also argue that we shouldn't fall into the trap of assuming that all Fedora users, or even all developers, are fully aware of how these different components do or why they might need them. Not everyone knows how Linux distros are put together, or where their firmware updates come from, or that there's such a thing as end of life. "If they use the CLI then they know what they're doing" is a great example of false consensus effect.

In Fedora and Red Hat a huge amount of work goes into updates and the software updating experience in general, across multiple types of software - regular updates, security updates, Flatpaks, firmware, etc. We don't do that for the sake of it - we do it because it improves the experience for the user. It keeps their data safe. It fixes bugs. It makes their hardware work better. That's why we do it, and it's what someone (potentially inadvertently) loses when they remove Software.

It's not an essential component of the system; we don't really want to encourage it to be removed, but nothing is going to break asides from automatic updates, and anyone using dnf to remove gnome-software ought to be well aware of that.

I'd argue that warning users about outstanding security updates, or that their system has reached end of life, is an essential system function. At some point we have to take responsibility for the user's experience.

tilex has a much smaller, but vocal, following among users who like GNOME 3 design patterns and/or tiling. It looked like a modern GNOME 3 app long before gnome-terminal did, and it tiles. I've never tried it, but I guess that's basically it.

People can use whatever terminal they want - no one's arguing that they shouldn't. The question is whether they should be able to remove the default terminal.

All these components are completely replaceable, and there's no negative effect on the system if they are replaced with capable alternatives.

If you don't have another terminal installed, sudo dnf remove gnome-software gnome-terminal leads to a pretty broken state, no?

People can use whatever terminal they want - no one's arguing that they shouldn't. The question is whether they should be able to remove the default terminal.

If you have installed an alternative terminal, there's no reason to keep the default terminal installed. Many users prefer to remove applications they don't use.

If you don't have another terminal installed, sudo dnf remove gnome-software gnome-terminal leads to a pretty broken state, no?

It would be a silly thing to do, but you can switch to a tty to reinstall if you get into that state. I think the solution here is to get Silverblue to a state where it can become default, rather than adding limits in dnf.

@kalev There have been multiple blog posts written about broken behavior in GNOME Software. Offhand, I know that Dedoimedo repeatedly dings us for GNOME Software:

• Fedora 32: https://www.dedoimedo.com/computers/fedora-32.html
• Fedora 31: https://www.dedoimedo.com/computers/fedora-31.html
• Fedora 30: https://www.dedoimedo.com/computers/fedora-30.html
• Fedora 29: https://www.dedoimedo.com/computers/fedora-29-gnome-second-old-laptop-nvidia.html

A consistent theme in there is that GNOME Software is sluggish and doesn't do what he expects as a user.

There are other complaints in there, but those deserve their own tickets.

@kalev There have been multiple blog posts written about broken behavior in GNOME Software.

How is this related to the discussion here and what am I supposed to do with this information?

@kalev Sorry, I tagged the wrong person. I meant to tag @aday.

Anyway we don't need to focus on specific quality issues with GNOME Software in this issue. Point is just that I suspect a lot of otherwise-happy Fedora users will start searching for a new distro if we lock them into keeping GNOME Software installed. (There are also many users who don't ever want automatic updates, they always want to be in control.)

Please don't lock GNOME Software. Users often wrote how they are happy after removing
GNOME Software + PackageKit which consume more RAM than whole GNOME and system. Even if this not a problem in 2020 some users still like to remove them to save some memory.

Some upstream issues: https://gitlab.gnome.org/GNOME/gnome-software/-/issues/941

It would be a silly thing to do

Ensuring the integrity of the system is our responsibility. If users end up breaking their systems, the silliness is ours, not theirs.

can switch to a tty to reinstall if you get into that state

In my experience it's not always obvious or easy to get to a tty. I don't consider ttys to be something we can rely on or expect people to know about.

I have to agree with everyone here who is saying that gnome-software should not be made not uninstallable at the dnf level.

gnome-software is a huge, really really huge resource hog and on systems with < 4G RAM this is really a problem. I myself just use "dnf update" on those and I have the following in my /etc/rc.d/rc.local to avoid gnome-software from auto-starting:

rm -f /etc/xdg/autostart/gnome-software-service.desktop

(as well as having disabeled the search provider)

I've not uninstalled it since I want to test various things using it, but I can see how for some users being able to just remove it is a good solution for the big resource drain which it causes.

As for making gnome-terminal non remove-able, to have a rescue terminal, meh. People who really mess this up can always do "ctrl + alt + F3" and login on a text console to do "dnf install <some-terminal>". Still making gnome-terminal not uninstallable is a lot less controversial since it does not auto-start like gnome-software does.

I realize this is not ideal, but until gnome-software becomes a lot more lean-and-mean (at least the always running parts), we really should allow removing it at the dnf level.

On Thu, Jul 23, 2020, at 10:30 AM, Neal Gompa wrote:

ngompa added a new comment to an issue you are following:
``
@kalev There have been multiple blog posts written about broken
behavior in GNOME Software. Offhand, I know that Dedoimedo repeatedly
dings us for GNOME Software:

• Fedora 32: https://www.dedoimedo.com/computers/fedora-32.html

The conclusion was very unhappy:

All in all, I've had moderate+ amounts of fun with Fedoras 29-31. Here, none at all. Fedora 32 is less capable than its predecessor, almost on all levels. Basic functionality is simply ... less. This is not good

Needless to say, I completely disagree. Fedora 32 has been the best yet!

I think we have consensus to make gnome-shell nonremovable with dnf. I'd also like to propose grub2 as well: removing that prevents the bootloader from being regenerated during kernel updates and results in users booting into the old kernel forever.

I have no objection to making both shim and grub2 non-removable, although for a different reason. Currently on UEFI, removing these package makes the system unbootable, because it'll remove the binaries from /boot/efi/.

The BLS snippets are generated by scripts in the kernel package. Anaconda uses grub2-mkconfig to create the initial grub.cfg, but this is not touched by subsequent kernel updates. Also conventional installs, the UEFI bootloader is updated by virtue of the package being updated, and on BIOS it's not updated automatically at all.

@javierm any comment? I don't think there are any conflicts between grub2, syslinux, and sd-boot - so I'm not expecting non-removable GRUB to be a problem.

Setting the meeting tag so the working group can decide on this. The relatively uncontroversial proposals for non-removable packages are:

• gnome-shell (which has gnome-control-center as a dependency)
• grub2
• shim

The more debatable ones are:

• gnome-software
• gnome-terminal
• yelp

gnome-shell (which has gnome-control-center as a dependency)
grub2
shim

The WG agreed to make these non-removable today, and @ngompa and @kalev are going to work on it. We didn't get chance to discuss the others.

I think making gnome-software uninstallable, or inextricably connected to gnome-shell, makes sense. Either gnome-software or gnome-terminal should be uninstallable, because either way someone can still get themselves out of an inadvertent situation.

fedora-release PRs to add gnome-shell to the protected packages list:

https://src.fedoraproject.org/rpms/fedora-release/pull-request/146
https://src.fedoraproject.org/rpms/fedora-release/pull-request/147

@ngompa has an action item to poke GRUB maintainers to make it nonremovable. They have PRs disabled so poking is the only option. Neal, how is that going?

Bug reports for grub2 and shim have been filed:

• grub2: https://bugzilla.redhat.com/show_bug.cgi?id=1874539
• shim: https://bugzilla.redhat.com/show_bug.cgi?id=1874541

The working group still needs to decide on the more "debatable" modules (see https://pagure.io/fedora-workstation/issue/165#comment-671594 ) - adding the meeting-request tag.

Agreed at today's meeting: yelp, gnome-software and gnome-terminal should continue to be removable with DNF. It shouldn't be possible to remove gnome-software with gnome-software though.

Bug reports for grub2 and shim have been filed:

• grub2: https://bugzilla.redhat.com/show_bug.cgi?id=1874539
• shim: https://bugzilla.redhat.com/show_bug.cgi?id=1874541

That leaves grub2 and shim as the only remaining problems.

grub2 is unfixed because the package maintainers do not accept pull requests (otherwise, Neal would have fixed it already). We might need to poke grub2 maintainers more to get their attention. It looks like shim allows pull requests, though.

Neal, can you do some poking here, please?

This is now done for grub2:

• https://src.fedoraproject.org/rpms/grub2/c/8c2cf1c36843a2eb1e52c29f20ef4167463189ec?branch=master
• https://src.fedoraproject.org/rpms/grub2/c/d84350c121ac5da35a2d5aef42908ac420f4d05f?branch=master

@javierm said he'd do shim soon-ish.

@javierm said he'd do shim soon-ish.

Adding pending-action for this.

This is now done for shim by @pjones: https://src.fedoraproject.org/rpms/shim/c/50b14368ca238ff2061e2ce0364726be7e7e5524