#654 f34/f35: Add plasma-pk-updater as optional in @kde-desktop.
Opened a month ago by kkofler. Modified a month ago
kkofler/fedora-comps readd-plasma-pk-updates  into  main

file modified
+2 -1
@@ -3166,7 +3166,7 @@ 

        <packagereq>plasma-breeze</packagereq>

        <packagereq>plasma-desktop-doc</packagereq>

        <packagereq>plasma-discover</packagereq>

-       <packagereq>plasma-discover-notifier</packagereq>

+       <packagereq type="default">plasma-discover-notifier</packagereq>

        <packagereq>plasma-drkonqi</packagereq>

        <packagereq>plasma-nm</packagereq>

        <packagereq>plasma-nm-l2tp</packagereq>
@@ -3190,6 +3190,7 @@ 

        <packagereq type="mandatory">sddm</packagereq>

        <packagereq type="mandatory">sddm-breeze</packagereq>

        <packagereq type="mandatory">sddm-kcm</packagereq>

+       <packagereq type="optional">plasma-pk-updates</packagereq>

        <packagereq type="conditional" requires="at-spi2-core">qt-at-spi</packagereq>

      </packagelist>

    </group>

file modified
+2 -1
@@ -3167,7 +3167,7 @@ 

        <packagereq>plasma-breeze</packagereq>

        <packagereq>plasma-desktop-doc</packagereq>

        <packagereq>plasma-discover</packagereq>

-       <packagereq>plasma-discover-notifier</packagereq>

+       <packagereq type="default">plasma-discover-notifier</packagereq>

        <packagereq>plasma-drkonqi</packagereq>

        <packagereq>plasma-nm</packagereq>

        <packagereq>plasma-nm-l2tp</packagereq>
@@ -3191,6 +3191,7 @@ 

        <packagereq type="mandatory">sddm</packagereq>

        <packagereq type="mandatory">sddm-breeze</packagereq>

        <packagereq type="mandatory">sddm-kcm</packagereq>

+       <packagereq type="optional">plasma-pk-updates</packagereq>

        <packagereq type="conditional" requires="at-spi2-core">qt-at-spi</packagereq>

      </packagelist>

    </group>

And explicitly make plasma-discover-notifier type="default" or some
tools will treat it as mandatory.

Metadata Update from @siosm:
- Request assigned

a month ago

The package was retired, but I have unretired it:

https://pagure.io/releng/issue/10107

https://bodhi.fedoraproject.org/updates/FEDORA-2021-343de58200

The Discover notifier is not a fully functional replacement:

https://lists.fedoraproject.org/archives/list/kde@lists.fedoraproject.org/thread/FHMJNZDMIKZNCKQMAO76NTGFLGX4F4GG/

and it also depends on the main Discover application, which some people (including me) do not use (because Dnfdragora is really the better package manager, but the Dnfdragora update notifier is also not a good replacement for plasma-pk-updates).

plasma-pk-updates is AFAIK dead upstream and we are looking at improving Discover & its notifier instead so we can not install both at the same time.

Sorry, this can't go in kde-desktop.

Adding anything to the comps group, even if only optional, means it will get installed on the spin too, and we can't have that.

Pull-Request has been closed by siosm

a month ago

We discussed that during the KDE SIG weekly meeting and for now we want to focus on Discover notifier as the default experience. Keeping the pk-updater available in Fedora is fine but we won't include it on the ISOs / install it by default.

Adding anything to the comps group, even if only optional, means it will get installed on the spin too, and we can't have that.

As far as I know, this is not true, but instead only mandatory and default components are installed on the spin, not optional components.

Pull-Request has been reopened by kkofler

a month ago

The goal of adding this component as optional is that users can install it manually using dnfdragora. It is explicitly not my intention to install it by default.

As far as I know, this is not true, but instead only mandatory and default components are installed on the spin, not optional components.

Evidence that this is correct: fedora-kde-common.ks includes the @libreoffice group, which includes the following optional packages:

      <packagereq type="optional">libreoffice-base</packagereq>
      <packagereq type="optional">libreoffice-draw</packagereq>
      <packagereq type="optional">libreoffice-math</packagereq>
      <packagereq type="optional">libreoffice-pyuno</packagereq>

Of these, only libreoffice-pyuno ends up on the live image, probably as a dependency of other LibreOffice packages, the others are not on the KDE Live image. Hence, I do not see how adding plasma-pk-updates as optional would affect the spin in any way. Thus, I reiterate my pull request.

(see https://kojipkgs.fedoraproject.org//vol/fedora_koji_archive03/packages/Fedora-KDE-Live/34/1.2/data/logs/image/x86_64/livemedia-out.log for what actually ends up on the spin, you can see that the optional libreoffice-{base,draw,math} are not included)

Ping? Can you please reconsider merging this merge request? As I explained above, the merge request does not interfere with this KDE SIG decision:

Keeping the pk-updater available in Fedora is fine but we won't include it on the ISOs / install it by default.

in any way. The merge request actually does not affect what is installed on the live image (nor what the netinstall installs by default) at all. All it does is make the package appear as an option when browsing the @kde-desktop group in dnfdragora. optional packages are by definition not installed by default (see my evidence above if you do not believe me), default packages are.

We will discuss that again in the KDE SIG meeting today

Why are you adding type="default" to plasma-discover-notifier?

And explicitly make plasma-discover-notifier type="default" or some
tools will treat it as mandatory.

Which tools?

And explicitly make plasma-discover-notifier type="default" or some
tools will treat it as mandatory.

Which tools?

At least the old yum was defaulting to "mandatory". If you can assure me that DNF and all other modern tools will treat no specified type as "default" (i.e., that it will not want to remove the entire group if the user removes plasma-discover-notifier), then adding type="default" explicitly is indeed not necessary (though to be honest, I would rather see the type explicitly specified everywhere, in case the old "mandatory" default from the yum era comes back from somewhere to bite us).

Though we haven't always been applying it equally, the official policy for this repo is that new additions must specify the type explicitly.