Bug 1449134 - KDE has two SW management/updater applications/icons on the Task manager
Summary: KDE has two SW management/updater applications/icons on the Task manager
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: dnfdragora
Version: 26
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Christian Dersch
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-05-09 09:31 UTC by Tomas Toth
Modified: 2018-01-01 22:13 UTC (History)
8 users (show)

Fixed In Version: dnfdragora-1.0.1-8.git20171229.24e4647.fc27 dnfdragora-1.0.1-8.git20171229.24e4647.fc26
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-12-31 21:29:28 UTC


Attachments (Terms of Use)

Description Tomas Toth 2017-05-09 09:31:36 UTC
Description of problem:
After some updates there are two SW management/updater icons (applet/widget/plasmoid whatever it is called...) on the KDE's Task manager panel:
  - KDE's SW Updates
  - DnfDragora

This may be confusing for some (beginner) users.


Version-Release number of selected component (if applicable):
dnfdragora.noarch         1.0.1-5.git20170505.2a3b056.fc26
dnfdragora-gui.noarch     1.0.1-5.git20170505.2a3b056.fc26

plasma-desktop.x86_64     5.9.5-1.fc26
plasma-pk-updates.x86_64  0.2-11.20160307git73b70b3.fc26
  Assuming this is the KDE's SW updater.


How reproducible:
Always.

Steps to Reproduce:
1. Login to KDE5.
2. See the two icons on the Task Manager bar. The KDE's SW updater may be hidden under 'Show hidden icons'.


Expected results:
One SW managing/updating application (by default).


Additional info:
My personal preference would be to keep the dnf based dnfDragora as it is 10x faster on checking updates, etc. as the slow packagekit based KDE's SW updates.
Hey, but that is just my preference.

I assigned it plasma-pk-updates component, please reassign it as needed.

Comment 1 Rex Dieter 2017-05-09 13:02:18 UTC
Not much to do there, they serve to different primary purposes:

plasma-pk-updates : notify/install updates

dnfdragora : package management (and can also manually install updates)

Comment 2 Christian Dersch 2017-05-09 15:27:06 UTC
dnfdragora should not enable the tray icon in all cases. Reassigning.

Comment 3 Christian Dersch 2017-05-10 14:40:20 UTC
I changed kde-desktop package group to fix this: https://pagure.io/fedora-comps/pull-request/121

Comment 4 Yaakov Selkowitz 2017-06-16 08:00:28 UTC
That is insufficient.  If, for example, a user installs another desktop (e.g. MATE) on top of either a KDE or Workstation installation, then dnfdragora-gui will  be installed, and then the tray icon ends up starting on either desktop.  However, both GNOME and KDE have their own GUI package managers, so it should only start on other desktops.

Therefore, the following should be added to /etc/xdg/autostart/org.mageia.dnfdragora-updater.desktop:

NotShowIn=GNOME;KDE;

Comment 5 Neal Gompa 2017-06-20 01:26:55 UTC
No, that's the wrong solution.

The correct solution is to move dnfdragora-gui Provides to dnfdragora and just add an updater subpackage for the updater and just not ship it by default.

Forcefully disabling the ability for the updater to be shown is a completely dumb move, since someone may very well want it instead of plasma-pk-updates.

Comment 6 Yaakov Selkowitz 2017-06-20 01:56:19 UTC
(In reply to Neal Gompa from comment #5)
> The correct solution is to move dnfdragora-gui Provides to dnfdragora and
> just add an updater subpackage for the updater and just not ship it by
> default.

These are not mutually exclusive.  I agree that dnfdragora-updater (currently shipped in dnfdragora-gui) should not be shipped on the KDE spin.  However, even if it is later installed (e.g. together with a second desktop on a multi-user workstation), that does NOT mean it should run by default even on those desktops (namely GNOME and KDE) with their own package management interfaces.  Therefore, NotShowIn should still be added to the updater's *autostart* entry.  (Not to be confused with the GUI's normal desktop entry, shipped in the main dnfdragora package, which of course should still remain available.)
 
> Forcefully disabling the ability for the updater to be shown is a completely
> dumb move, since someone may very well want it instead of plasma-pk-updates.

Then, like any other desktop default, it can be overridden in settings (System Settings -> Startup and Shutdown -> Autostart).  Should we not make Kwrite the default text editor just because someone might prefer Gedit or Pluma?  Each desktop should have sane default behaviours, regardless of what else may be installed on the system, while allowing the user to configure their preferences with deliberate action on their part.

Comment 7 Neal Gompa 2017-06-20 02:04:44 UTC
> Should we not make Kwrite the default text editor just because someone might prefer Gedit or Pluma?

We don't forcefully hide applets, though. If they're installed, then it's obvious that the user wants them, and so they show up.

Your approach means that *even if it's installed, it won't show up*. There is no obvious way for a user to figure out how to make it show up.

Thus, dumb move. Respect the user's intent and if they are installing an optional component, that means they want to use it.

Not to mention, doing this will break downstreams that are explicitly choosing to swap default updaters in their package sets (such as Korora, which used yumex-updater historically and will switch to dnfdragora-updater for K26).

Comment 8 Neal Gompa 2017-06-20 02:05:22 UTC
Oh, and your example is invalid, because when you install gedit or pluma, they're not hidden in Plasma. You can find them and open them just like any other.

Comment 9 Yaakov Selkowitz 2017-06-20 02:26:24 UTC
(In reply to Neal Gompa from comment #7)
> We don't forcefully hide applets, though. If they're installed, then it's
> obvious that the user wants them, and so they show up.

This is not a KDE component.  Therefore, its installation is NOT necessarily an indication that the user wants to use it.  It may be pulled in by another desktop (e.g. MATE) which is installed for use by another user (a multi-user workstation) or for testing purposes only, in which case this user still expects their Plasma desktop to act in a default fashion unless and until they set it otherwise.

> Your approach means that *even if it's installed, it won't show up*. There
> is no obvious way for a user to figure out how to make it show up.

Is it obvious how to change the default text editor?  I know how, but I've been building KDE for over a decade.  I wouldn't call it extremely obvious, however.

> Thus, dumb move. Respect the user's intent and if they are installing an
> optional component, that means they want to use it.

As this isn't a KDE component, that may not be the intent.  If a user installs gedit, should we then assume they want it to become the default text editor?  We don't, and rightfully so.

> Not to mention, doing this will break downstreams that are explicitly
> choosing to swap default updaters in their package sets (such as Korora,
> which used yumex-updater historically and will switch to dnfdragora-updater
> for K26).

That shouldn't force our behaviour, as they would anyways have to make changes along those lines.

> Oh, and your example is invalid, because when you install gedit or pluma,
> they're not hidden in Plasma. You can find them and open them just like any
> other.

The desktop entry is still visible, as I explicitly said in my previous comment.  I am only discussing the tray icon.

Comment 10 Edgar Hoch 2017-07-19 16:53:02 UTC
(In reply to Neal Gompa from comment #7)
> We don't forcefully hide applets, though. If they're installed, then it's
> obvious that the user wants them, and so they show up.

NO! That is a completely wrong assumption!

We install nearly all available desktops, because our systems are multiuser machines which different users use it on different times, for example in a computer pool for students, or for staff which prefer different desktops. I don't want to install a different set of rpm packages on each computer, so all computer gets all the same packages (currently about 15000 packages).

An installation of a packages does never mean that the software will be used. The intend of installation of a package is that the software is available and ready to use, no to start automatically. Suppose all packages would think as you - there would be many services and daemons running that will never be used, and they waste resources like memory and cpu time (and user distraction).

> Your approach means that *even if it's installed, it won't show up*. There
> is no obvious way for a user to figure out how to make it show up.

Yes, EVEN IF IT IS INSTALLED, it should NOT START for ALL desktops but only for these for which the application was designed - or better not autostart at all if the user can start it manually.

> Thus, dumb move. Respect the user's intent and if they are installing an
> optional component, that means they want to use it.

Yes, please do what you write: Respect the user's intent! The intend is to provide the software. You do not know if the user wants to use it!

As in our case, we have installed many desktops concurrently, and only one will be used by a desktop user at a time. If the user chooses GNOME, he don't want to get applications from other desktops autostarted, and, of course, he don't want to used different package managers run at the same time!

Why do you think you know better what an user wants to run, but the user himself?


> Not to mention, doing this will break downstreams that are explicitly
> choosing to swap default updaters in their package sets (such as Korora,
> which used yumex-updater historically and will switch to dnfdragora-updater
> for K26).

Downstreams can change whatever they want... - so it is not necessary to bother Fedora users by popping up dnfdragora update messages serveral times a day.


To conclude, either
- /etc/xdg/autostart/org.mageia.dnfdragora-updater.desktop should be removed completely (users can set autostart in their own configuration),
- /etc/xdg/autostart/org.mageia.dnfdragora-updater.desktop is started only these desktops which use it as the (only) package manager.

In the last case /etc/xdg/autostart/org.mageia.dnfdragora-updater.desktop should not a negative list using a NotShowIn= line as suggested in comment #4, but it should use a positive list using a OnlyShowIn= line, becuase there may be more desktops than GNOME and KDE that are installed but use another package manager.

I can modify /etc/xdg/autostart/org.mageia.dnfdragora-updater.desktop myself and add such a line, but autostart files are not declared as configuration files and are overwritten on updates, so my changes will be lost after an update (done by dnf-automatic, for example).

I can (force) deinstallation of packages dnfdragora and dnfdragora-gui, but then users that want to use it cannot use it, so this is not an acceptable solution.

Comment 11 Edgar Hoch 2017-07-19 18:32:41 UTC
Oh, just to note:

I just checked the notification list.
dnfdragora has send me a desktop notification that 642 updates are available EVERY THREE HOURS!

Comment 12 Yaakov Selkowitz 2017-07-19 19:56:06 UTC
(In reply to Edgar Hoch from comment #10) 
> To conclude, either
> - /etc/xdg/autostart/org.mageia.dnfdragora-updater.desktop should be removed
> completely (users can set autostart in their own configuration),

I disagree; we clearly want an updater -- the right one, and only one at a time -- running by default.

> - /etc/xdg/autostart/org.mageia.dnfdragora-updater.desktop is started only
> these desktops which use it as the (only) package manager.
>
> In the last case /etc/xdg/autostart/org.mageia.dnfdragora-updater.desktop
> should not a negative list using a NotShowIn= line as suggested in comment
> #4, but it should use a positive list using a OnlyShowIn= line, becuase
> there may be more desktops than GNOME and KDE that are installed but use
> another package manager.

This needs to be looked at with future desktops in mind.  We know which desktops we have today, and which have their own GUI package managers.  It is far more likely for a new desktop to be created *without* its own package manager than for one to be created with, or even for an existing one to suddenly get one.

While, obviously, there is no solution that is 100% future-proof, but using NotShowIn would cover any new desktops, where OnlyShowIn would not.

Comment 13 Edgar Hoch 2017-07-19 20:36:36 UTC
(In reply to Yaakov Selkowitz from comment #12)
> I disagree; we clearly want an updater -- the right one, and only one at a
> time -- running by default.

Is it really prefered to run manual updates by users? I think this is the task for dnf-automatic ?

I agree that updates should be applied regularly to any linux system.

In a managed environment normal users does not have (and should not have) the right to install or updates packages. It is the task of an administrator to do it or to configure automatic updates.

Another environment may be private use, for example, where there is no explicit administrator, and the user is the administrator of his own system.


The only problems of dnf-automatic I see are:

- It may run at a time when the user don't want it (because it creates high loads on cpu and disk). Without modification it is run every 24 hours after power-on.

- If there are dependency or other problems that stops running upgrade by dnf-automatic there is no notification of the user. We need to check /var/log/dnf.rpm.log or try "dnf upgrade" to verify that the list is short, or have another application that tells when there is a problem.



(In reply to Yaakov Selkowitz from comment #12)
> This needs to be looked at with future desktops in mind.  We know which
> desktops we have today, and which have their own GUI package managers.  It
> is far more likely for a new desktop to be created *without* its own package
> manager than for one to be created with, or even for an existing one to
> suddenly get one.
> 
> While, obviously, there is no solution that is 100% future-proof, but using
> NotShowIn would cover any new desktops, where OnlyShowIn would not.

Ok, you have other preferences, if it works then all is fine for me.



PS: I don't know who is responsible for this problem. May be that you can forward it the right discussion place?

Files in /etc/xdg/autostart/ that belong to a package are not configurable by an administrator to set system-wide defaults. They are not declared as config files and are overwritten by updated packages.

I think that defaults for autostart should go to somewhere in /usr/lib* or /usr/share. Administators should be able to overwrite these defaults by creating files in /etc/xdg/autostart/. See the example of systemd - files in /etc/systemd/ overwrite or supplement (in case of *.d/ directory) the systemd defaults.

This would solve many problems and discussions of autostart files (like this), because package maintainers may set there default, and host administators may change it if they require it.

Comment 14 Fedora Update System 2017-12-29 23:25:34 UTC
dnfdaemon-0.3.18-5.fc27 dnfdragora-1.0.1-8.git20171229.24e4647.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-d66bd84f06

Comment 15 Fedora Update System 2017-12-29 23:29:01 UTC
dnfdaemon-0.3.18-5.fc26 dnfdragora-1.0.1-8.git20171229.24e4647.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-8caadb4a1b

Comment 16 Fedora Update System 2017-12-30 19:55:44 UTC
dnfdaemon-0.3.18-5.fc27, dnfdragora-1.0.1-8.git20171229.24e4647.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-d66bd84f06

Comment 17 Fedora Update System 2017-12-30 20:41:31 UTC
dnfdaemon-0.3.18-5.fc26, dnfdragora-1.0.1-8.git20171229.24e4647.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-8caadb4a1b

Comment 18 Fedora Update System 2017-12-31 21:29:28 UTC
dnfdaemon-0.3.18-5.fc27, dnfdragora-1.0.1-8.git20171229.24e4647.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.

Comment 19 Fedora Update System 2018-01-01 22:13:01 UTC
dnfdaemon-0.3.18-5.fc26, dnfdragora-1.0.1-8.git20171229.24e4647.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.