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 726819 - software sources: don't lie
software sources: don't lie
Status: RESOLVED OBSOLETE
Product: gnome-software
Classification: Applications
Component: General
unspecified
Other Linux
: Normal normal
: ---
Assigned To: GNOME Software maintainer(s)
GNOME Software maintainer(s)
: 730454 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2014-03-21 12:58 UTC by Matthias Clasen
Modified: 2018-01-24 16:50 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Improve a misleading string (1.17 KB, patch)
2015-05-23 17:29 UTC, Matthias Clasen
committed Details | Review
Comparison of the Sources dialog with different locales (252.07 KB, image/png)
2015-08-31 22:02 UTC, Rafal Luzynski
  Details
Fixes the problem with the label being too wide (1.13 KB, patch)
2015-09-02 21:34 UTC, Rafal Luzynski
committed Details | Review
Fixes one more misleading string (1.32 KB, patch)
2015-10-02 22:13 UTC, Rafal Luzynski
accepted-commit_now Details | Review

Description Matthias Clasen 2014-03-21 12:58:19 UTC
I am seeing the 'Google Talk' repo show up in the dialog. But because gnome-software doesn't consider the google-talk-plugin package to be worthy, it says
"No software from this source installed". Thats a lie, and it may mislead me into removing the repository, causing me not to get updates for the google talkplugin anymore.

I'd suggest to say something like:

"No applications or addons from this source installed, but other software from this source is present on your system."
Comment 1 Allan Day 2014-04-11 08:26:44 UTC
We certainly have to indicate that something is installed. Maybe we could fall back to a more ambiguous category when we can't identify installed software as an app/addon?

"2 items installed"
Comment 2 Michael Catanzaro 2015-05-12 13:24:15 UTC
*** Bug 730454 has been marked as a duplicate of this bug. ***
Comment 3 Matthias Clasen 2015-05-23 17:29:41 UTC
Created attachment 303866 [details] [review]
Improve a misleading string

Just because we didn't find something that fits our narrow
definition of 'app' or 'addon' doesn't mean a nothing is installed
from a repo. So don't give that impression to the user.
Comment 4 Kalev Lember 2015-05-24 11:17:38 UTC
I am not sure it's a huge improvement to say "other software might still be". It doesn't actually add any useful information to the user to decide whether the repo is safe to remove or not.

Maybe a solution would be to list individual packages in the dialog, in addition to apps / addons? We are already doing a similar thing in the updates page where individual packages are shown, but in a second level, clumped together under the "OS Updates" item. Could do a similar thing here as well.
Comment 5 Matthias Clasen 2015-05-24 13:33:27 UTC
(In reply to Kalev Lember from comment #4)
> I am not sure it's a huge improvement to say "other software might still
> be". It doesn't actually add any useful information to the user to decide
> whether the repo is safe to remove or not.

The main point was to get away from the lie "no software".

> Maybe a solution would be to list individual packages in the dialog, in
> addition to apps / addons? We are already doing a similar thing in the
> updates page where individual packages are shown, but in a second level,
> clumped together under the "OS Updates" item. Could do a similar thing here
> as well.

I don't think we really have to list the packages. just saying "Other software" might be good enough.
Comment 6 Rafal Luzynski 2015-05-25 09:10:55 UTC
I've already discussed this with Matthias on IRC and now I repeat it here to let you all read my opinion. I think we can easily count other packages (those which are neither "applications" nor "add-ons") and display "No software installed" when there is really no software installed and "Some software is installed" (truly *is* rather than *might be*) when there is some. Optionally we can display a number of those "other" packages. Now as I watch the source code I can see it is even easier than I initially thought: we don't have to count anything, related->len is the number we need because if cnt_apps==cnt_addon==0 then related->len counts only those "other" packages.

This is only a question to Richard and other PK experts: does related=gs_app_get_related(app) array really always contain all packages and can we safely say that if related->len==0 then there are really no packages installed and it is safe to remove the source without any consequences? Or is it safe when related->len==1 because the source also counts itself as 1? How does it work when the source is installed manually, when *.repo file does not belong to any package? How does it work with Google Chrome which currently reports there is no software installed?
Comment 7 Rafal Luzynski 2015-05-27 09:16:12 UTC
(In reply to Rafal Luzynski from comment #6)
> [...]
> This is only a question to Richard and other PK experts: does
> related=gs_app_get_related(app) array really always contain all packages and
> can we safely say that if related->len==0 then there are really no packages
> installed and it is safe to remove the source without any consequences?

I've talked to Richard on IRC and he explained me that these results are reliable when we use PackageKit and yum but *not* when we use dnf. We need a plugin for dnf to perform the database synchronization and provide the reliable results, like yum-packagekit (see also: bug 725001 comment 4). Now since yum has been obsoleted and dnf became default in F22 this is really an issue.

So, indeed we can't reliably tell that there is absolutely no software installed from a particular repo and we have to display something like "other software might still be."

(Hey, actually we can't even tell there are no apps or addons, can we? Or maybe a backend should tell whether its results are reliable and whether the message should be "no software" or "some software" or "maybe", for PackageKit with dnf the result would be "maybe?")

> Or is it safe when related->len==1 because the source also counts itself as 1?

Also Richard explained that "the source isn't counted as a package *unless* there's a rpmfusion-release type package."
Comment 8 Rafal Luzynski 2015-08-09 09:35:36 UTC
Review of attachment 303866 [details] [review]:

Since we can't do anything better at the moment due to the problems between PK and dnf my opinion, fwiw, is to commit this patch.
Comment 9 Matthias Clasen 2015-08-23 16:53:02 UTC
Attachment 303866 [details] pushed as e2ad6a4 - Improve a misleading string
Comment 10 Michael Catanzaro 2015-08-23 23:27:44 UTC
(In reply to Rafal Luzynski from comment #8)
> Review of attachment 303866 [details] [review] [review]:
> 
> Since we can't do anything better at the moment due to the problems between
> PK and dnf my opinion, fwiw, is to commit this patch.

Maybe we can't be sure what is installed, but surely we can say what will be _removed_!
Comment 11 Michael Catanzaro 2015-08-25 00:35:50 UTC
Explanation: PackageKit obviously can't remove anything it doesn't know about. So in theory, we can display the number of packages from the source that will be removed, rather than just saying "maybe something is installed maybe not." The problem is, I think PackageKit has no nice way to simulate a RemoveRepo operation and see what would be removed. I think we can work around that by performing GetDepends on every PackageKit GsApp that will be removed. Then that also allows us to fail the operation if a system package is in the dependency set. So instead of saying "No applications or addons installed, other software might still be" we can say "No software will be removed if this source is removed" or "98528 software packages will be removed if this source is removed" or "This source cannot be removed because it has replaced critical system software"; something like that.

Question: How will you get a list of packages to run GetDepends on if listing the packages from a repo is broken?

Answer: I presume that the packages missing from that list will also not be removed by the RepoRemove operation. If that's not true then my plan is bogus. If that is true, then the packages that are missing from the list of packages to run GetDepends on (which is the result of gs_app_get_related_apps) are not going to be removed: they are lost to time and space, so we just don't count them.
Comment 12 Rafal Luzynski 2015-08-27 10:17:04 UTC
I'm afraid we have to reopen this bug.

1. Even although the string in the list of software sources has been fixed you can click the software source (maybe going to remove it) and the text inside again says "No software installed from this source" which may not be true. The line is here: https://git.gnome.org/browse/gnome-software/tree/src/gs-sources-dialog.ui#n243
2. The new string "No applications or addons installed; other software might still be" is long. Not too long in English but in some other languages it causes the dialog box to be very wide which looks bad. Not all translations are yet ready. So far I can tell it looks bad in Polish and Slovak. Maybe the translators should insert the line break explicitly, maybe the widget label should wrap its contents. It's not a big issue, just a matter of appearance.
3. Michael has some ideas about how to tell reliably that there is indeed or there is absolutely no software installed from a source. I think this will not work for the same reasons as explained in comment 7 but my knowledge about PackageKit is too little to discuss it. I think it's Richard who should answer.
Comment 13 Michael Catanzaro 2015-08-27 15:51:01 UTC
Richard suggested adding a simulate flag to the RemoveRepo action, so we can easily figure out what is going to be removed without any workarounds.
Comment 14 Rafal Luzynski 2015-08-31 22:02:55 UTC
Created attachment 310382 [details]
Comparison of the Sources dialog with different locales

(In reply to Rafal Luzynski from comment #12)
> [...]
> 2. The new string "No applications or addons installed; other software might
> still be" is long. Not too long in English but in some other languages it
> causes the dialog box to be very wide which looks bad.
Comment 15 Rafal Luzynski 2015-09-02 21:34:46 UTC
Created attachment 310547 [details] [review]
Fixes the problem with the label being too wide
Comment 16 Richard Hughes 2015-09-08 10:50:24 UTC
Review of attachment 310547 [details] [review]:

Thanks!
Comment 17 Rafal Luzynski 2015-10-02 22:13:43 UTC
Created attachment 312592 [details] [review]
Fixes one more misleading string

Is this what we want? This should close the issue.
Comment 18 Matthias Clasen 2015-10-06 22:24:49 UTC
Review of attachment 312592 [details] [review]:

Looks good to me
Comment 19 Piotr Drąg 2018-01-16 16:23:35 UTC
Review of attachment 312592 [details] [review]:

So this is accepted-commit_now for a while now, shouldn’t we push it?
Comment 20 GNOME Infrastructure Team 2018-01-24 16:50:41 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/10.