I think the basic idea is that apps are self contained blobs, so you can remove one without removing half the system. Apps that are system apps should not be removable, and "apps" like usermode should probably not be shown at all.

Agreed, you should consider blacklisting usermode-gtk and chainsaw then :)

usermode-gtk blacklisted, I'll try to work out if we can untangle chainsaw.

Any news on chainsaw ? By the way you should consider to blacklist xterm as well.

Maybe set up some kind of interface or a dedicated bug report would be great to keep track for blacklist request ?

Thanks ! I deeply enjoy the new software center, something I've been waiting for a long time !

Apps pulling in apps isn't a very good user experience, so I would recommend that you file this as a downstream bug (I myself installed Eclipse and was pretty annoyed to find a bunch of other apps installed that I never asked for).

That said, we do show a confirmation dialog when you go to remove app. Maybe an additional line of information would be OK:

"Eclipse will also be removed"

I wouldn't want to spend too much time on this though - the lack of feedback isn't the real bug here.

(In reply to comment #5)
> That said, we do show a confirmation dialog when you go to remove app. Maybe an
> additional line of information would be OK:
> 
> "Eclipse will also be removed"

We can do this, although this involves a test-depsolve which takes a couple of seconds. Also, in the pathological case we could list quite a few apps here so some mockups would be very welcome.

> I wouldn't want to spend too much time on this though - the lack of feedback
> isn't the real bug here.

What about as a stop-gap, just stop users from removing applications that also remove other applications? "Sorry dave, can't do that" type thing.

Richard.

(In reply to comment #6)
> > That said, we do show a confirmation dialog when you go to remove app. Maybe an
> > additional line of information would be OK:
> > 
> > "Eclipse will also be removed"
> 
> We can do this, although this involves a test-depsolve which takes a couple of
> seconds. 

This is essentially a packaging bug, so I don't think we should spend too much time over it, or let it affect the overall experience too much.

We don't have to be too sophisticated. Maybe we could flag apps that install apps at install time, or something?

> Also, in the pathological case we could list quite a few apps here so
> some mockups would be very welcome.

I'm just talking about an extra string in the dialog, with a list of apps that will be removed.

> > I wouldn't want to spend too much time on this though - the lack of feedback
> > isn't the real bug here.
> 
> What about as a stop-gap, just stop users from removing applications that also
> remove other applications? "Sorry dave, can't do that" type thing.

Err, we can't stop people from uninstalling apps...

*** Bug 710343 has been marked as a duplicate of this bug. ***

As I wrote in https://bugzilla.gnome.org/show_bug.cgi?id=710343 (and still believe), blacklisting seems very much the wrong way to go about this. It needs a fix that doesn't need constant maintenance and won't almost inevitably be wrong in both directions sometimes, which is what always happens with blacklists.

"I suspect there'll always be some reason why something with deps will show up
in Software's list, unless you simply force it never to display any package on
which any other package depends and make that really robust...so you'd either
have to do that, or handle displaying dependencies somehow."

(In reply to comment #9)
> As I wrote in https://bugzilla.gnome.org/show_bug.cgi?id=710343 (and still
> believe), blacklisting seems very much the wrong way to go about this. It needs
> a fix that doesn't need constant maintenance and won't almost inevitably be
> wrong in both directions sometimes, which is what always happens with
> blacklists.
...

I generally agree with you here, Adam. Hiding apps that don't play by the rules doesn't seem like the right way to go - what if someone actually needs that app? Instead, we should 1) file downstream bugs 2) warn the user when removing apps that have dependencies.

Regarding 2, a mockup isn't really needed here. The current dialog reads:

"<app> will be removed, and you will have to install it to use it again."

I would simply append the line "Due to the way it has been distributed, <app> will also be removed." for cases where there are dependencies.

I've stumbled into another example of this, Fedora 21 and Rygel Preferences. In Software, click on Remove and in about 15 seconds the entire GUI is yanked out from under me including gnome-shell, nautilus, gdm, mutter, ibus stuff, and a bunch of other applications... Thxbtrfssnapshots.
https://bugzilla.redhat.com/show_bug.cgi?id=1136579

(In reply to comment #10)
> I would simply append the line "Due to the way it has been distributed, <app>
> will also be removed." for cases where there are dependencies.

This isn't sufficient, since clearly packages that are not applications can be removed as well, plus your desktop environment.

Created attachment 302902 [details] [review]
GsInteractiveTask: asks the user a question if they really want to remove/install dependencies

This is an initial, very quick, dirty and ugly but working solution to this problem. Please take it as an example of how it could be solved. I am aware this patch needs work so please do not commit it (unless you want to create a wip branch).

Some remarks:
* Simulate question is not asked if there are no dependencies so probably we will have two message dialog boxes: first "Are you sure you want to remove..." as it is now and then a warning that other applications also will be removed. This is because we don't know if the second dialog will be shown until we try to remove; OTOH if we don't display the first dialog and there are no dependencies then the application will be removed without the user's confirmation.
* Simulate question lists only the dependencies, does not include the original application being removed.
* The solution seems to help not only with the removal with dependencies but also with the installation with dependencies and many similar actions which require the user's interaction. May also tell that the removal is impossible because it would require some core system components to be removed (see bug 723922).
* For testing purposes: Bijiben requires Evolution, when removing Evolution you will be prompted if you want to remove Bijiben. (My distro is F21; packagers: please don't fix this or we will lose a nice test case.)
* The plugin code should not probably do the GUI interaction, it should be passed to the main window.
* A note about the copyright message: it says "Copyright (C) 2009 Richard Hughes" because the new files gs-interactive-task.[ch] are actually copies of pk-task-text.[ch] from his PackageKit project (pkcon tool), with just the identifiers renamed to match GNOME Software and a message dialog added instead of printing to the console. Richard is the original author of both projects.

Any comments, hints and help will be appreciated.

*** Bug 750165 has been marked as a duplicate of this bug. ***

I update the summary because the solution is common for all cases, no matter if the user is installing, removing, upgrading, or downgrading a software and if it causes installing, removing, upgrading (*), or downgrading another one. Also note that although installation usually may cause installation of another software, removal may cause removal, and so on, in fact any combination is possible (e.g., installation may cause the upgrade of another software) and a common callback will be called listing all dependencies which may be of any possible kind.

_____________
(*) Actually, g-s does not provide the online upgrade and downgrade facility but PackageKit does so the API exists. All these cases are indistinguishable.

(In reply to Allan Day from comment #10)
> [...]
> Regarding 2, a mockup isn't really needed here. The current dialog reads:
> 
> "<app> will be removed, and you will have to install it to use it again."
> 
> I would simply append the line "Due to the way it has been distributed,
> <app> will also be removed." for cases where there are dependencies.

I agree that it's not worth to design a fancy custom dialog box, a simple default message dialog would be sufficient. But even a simple text message becomes complex when it must list both applications and add-ons to be removed. That's not only because of singular vs. plural grammatical number but also that multiple apps/add-ons require an enumeration (a list?) while single items should be just mentioned in a sentence. I have discussed this with Allan and he agrees that it is sufficient if we just list the applications to be removed/installed, not the add-ons. Often the add-ons are removed together with their application and it is normal, no need to display a confirmation to the user.

I think we should merge this after 3.20 branches. There are a few nits (like not using g_autoptr and g_autofree) but nothing I can't cope with if you're busy. Thanks Rafal.

Richard, please note this is only a rough idea rather than a complete solution. The worse thing in this patch is that it shows a dialog box from non-GUI thread. If you don't reject this idea then it encourages me to keep working on this task, also feel free to continue it yourself if you want. So first I'd like to figure out how to schedule an interactive dialog box from non-GUI thread and wait until a user answers in the GUI thread.

Any news regarding this issue?

Actually yes, see https://pagure.io/fedora-workstation/issue/13#comment-440501

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-software/issues/5.