After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 711171 - Warn user when installing/removing a software can also install/remove another one
Warn user when installing/removing a software can also install/remove another...
Status: RESOLVED OBSOLETE
Product: gnome-software
Classification: Applications
Component: General
3.13.x
Other Linux
: High critical
: ---
Assigned To: GNOME Software maintainer(s)
GNOME Software maintainer(s)
: 710343 750165 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2013-10-30 19:27 UTC by Maël Lavault
Modified: 2018-01-24 16:48 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
GsInteractiveTask: asks the user a question if they really want to remove/install dependencies (19.79 KB, patch)
2015-05-05 00:02 UTC, Rafal Luzynski
none Details | Review

Description Maël Lavault 2013-10-30 19:27:02 UTC
Hi,

It's quite problematic tonot show any dependencies between software when removing.

For example, I just wanted to remove chainsaw in gnome-software. When I did so, I also saw that eclipse was gone... Not a very good surprise. It seems that chainsaw was an eclipse dependency but it is listed as an completely different program in gnome software. So maybe some sort of warning could be great !

And it's not the only one, take usermode for example. It is listed as an independent app, but if you remove it,it also remove network-manager and some gnome control center stuff...

Thanks !
Comment 1 Richard Hughes 2013-10-31 08:18:57 UTC
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.
Comment 2 Maël Lavault 2013-11-01 15:35:30 UTC
Agreed, you should consider blacklisting usermode-gtk and chainsaw then :)
Comment 3 Richard Hughes 2013-11-01 19:12:32 UTC
usermode-gtk blacklisted, I'll try to work out if we can untangle chainsaw.
Comment 4 Maël Lavault 2013-11-05 22:40:21 UTC
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 !
Comment 5 Allan Day 2013-11-11 20:15:14 UTC
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.
Comment 6 Richard Hughes 2013-11-11 20:56:33 UTC
(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.
Comment 7 Allan Day 2013-11-11 23:35:10 UTC
(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...
Comment 8 Michael Catanzaro 2013-12-20 04:03:42 UTC
*** Bug 710343 has been marked as a duplicate of this bug. ***
Comment 9 Adam Williamson 2013-12-20 04:17:44 UTC
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."
Comment 10 Allan Day 2014-04-10 16:14:48 UTC
(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.
Comment 11 Chris Murphy 2014-09-03 22:26:03 UTC
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
Comment 12 Michael Catanzaro 2014-09-04 02:37:12 UTC
(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.
Comment 13 Rafal Luzynski 2015-05-05 00:02:55 UTC
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.
Comment 14 Rafal Luzynski 2015-06-01 22:10:56 UTC
*** Bug 750165 has been marked as a duplicate of this bug. ***
Comment 15 Rafal Luzynski 2015-06-01 22:25:43 UTC
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.
Comment 16 Rafal Luzynski 2015-08-13 13:16:04 UTC
(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.
Comment 17 Richard Hughes 2016-02-23 09:57:02 UTC
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.
Comment 18 Rafal Luzynski 2016-02-23 11:38:31 UTC
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.
Comment 19 AsciiWolf 2017-06-16 12:52:49 UTC
Any news regarding this issue?
Comment 20 Michael Catanzaro 2017-06-16 13:46:27 UTC
Actually yes, see https://pagure.io/fedora-workstation/issue/13#comment-440501
Comment 21 GNOME Infrastructure Team 2018-01-24 16:48:14 UTC
-- 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.