Bug 27683

Sorry, I provided the wrong URLs to Sophie (they point to the dependency lists for lib64webkit2gtk-gir4.0 and libwebkit2gtk-gir4.0, instead of lib64webkit2gtk4.0_37 and libwebkit2gtk4.0_37).

Here are the correct Sophie URLs:

# 64-bit

http://sophie.zarb.org/rpms/e4b63715e9808d8a34676802b66d579b/deps

# 32-bit

http://sophie.zarb.org/rpms/c74a52c576af7cda4b126adb84edbac0/deps

Created attachment 12030 [details]
The "New dependencies" list for the package "lib64webkit2gtk4.0_37"

Created attachment 12031 [details]
The "New dependencies" list for the package "lib64webkit2gtk-gir4.0

Based on the dependency list on Sophie (http://sophie.zarb.org/rpms/eb76dab251fc08a1d4dd54066d4fcbb4/deps), it seems that there's nothing wrong with the dependencies for this package - it's just that it depends on lib64webkit2gtk4.0_37, which does have the unnecessary dependencies.

You can avoid the recommended packages by installing the updates with --no-recommends.  The addition to the webkit2 SPEC file explains these additions pretty well.  As webkit2 is gtk-based, it does use xdg-portal-desktop-gtk, not the kde one.


# These are hard requirements of WebKit's bubblewrap sandbox.
Requires:      bubblewrap
Requires:      xdg-dbus-proxy

# If Geoclue is not running, the geolocation API will not work.
Recommends:    geoclue2

# If no xdg-desktop-portal backend is installed, many features will be broken
# inside the sandbox. In particular, the -gtk backend has to be installed for
# desktop settings access, including font settings.
Recommends:    xdg-desktop-portal-gtk

Assignee: bugsquad => nicolas.salguero
Resolution: (none) => INVALID
Status: NEW => RESOLVED
CC: (none) => thierry.vignaud

Created attachment 12032 [details]
urpmi --auto-select logs

Using or not using --no-recommends is not the question.
An update should not bloat a system in such proportions.
(see attached logs)

lib64webkit2gtk4.0_37 -> xdg-desktop-portal - > flatpack -> ostree
                                            -> pipewire

I think QA validation should also perform a deps test case such as:
ROOT=/tmp/T
mkdir $ROOT
urpmi --auto --root $ROOT --justdb --media Core\ Release basesystem-minimal
urpmi --auto --root $ROOT --justdb --media Core\ Release the_old_pkg
urpmi --auto-select --root $ROOT --justdb
# And then if quite a lot of new pkgs got installed, raise an alert

It could be automated by using a QA script

I've run urpmi with --bug a_dir_name before so I can provide you with an archive to use with urpmi --env if you want…

We've caught in QA incorrectly added dependencies (like devel ones to non-devel packages) before, but the added dependencies here were not incorrect, as I showed above, just a function again of the updated software (and the example you gave was still avoidable through not installing recommends).  You can complain upstream about the additions, but there's nothing else we could do.

(In reply to David Walser from comment #4)
> You can avoid the recommended packages by installing the updates with
> --no-recommends.  The addition to the webkit2 SPEC file explains these
> additions pretty well.  As webkit2 is gtk-based, it does use
> xdg-portal-desktop-gtk, not the kde one.
> 
> 
> # These are hard requirements of WebKit's bubblewrap sandbox.
> Requires:      bubblewrap
> Requires:      xdg-dbus-proxy
> 
> # If Geoclue is not running, the geolocation API will not work.
> Recommends:    geoclue2
> 
> # If no xdg-desktop-portal backend is installed, many features will be broken
> # inside the sandbox. In particular, the -gtk backend has to be installed for
> # desktop settings access, including font settings.
> Recommends:    xdg-desktop-portal-gtk

I apologise - I reported the bug against the wrong package.

I've looked through the SRPM spec files now, and as you say, it's reasonable for lib64webkit2gtk4.0_37 and libwebkit2gtk4.0_37 to depend on bubblewrap and xdg-dbus-proxy, and to recommend geoclue2 and xdg-desktop-portal-gtk.

I assume it's also reasonable for xdg-desktop-portal-gtk to depend on xdg-desktop-portal, but correct me if I'm wrong.

I think the problem probably lies with xdg-desktop-portal. According to http://sophie.zarb.org/rpms/3f0d690c1bf943da4a121fe7dc70b4db/files/2, the SRPM for xdg-desktop-portal contains the following line:

    # Required version for icon validator.
    Recommends:    flatpak >= 1.2.0

Can anyone provide clarification on what the "Required for icon validator" comment means? I'm guessing it just means that, if you intend to use xdg-desktop-portal with flatpak, you need to ensure that flatpak is updated to at least version 1.2.0.

If my assumption above is correct, then the Recommends: relationship would have made sense, at a time when xdg-desktop-portal was basically only utilised by flatpak; however, now that the WebKit stack has a use for it as well, xdg-desktop-portal should downgrade the relation to a Suggests:. Unless there's some feature of xdg-desktop-portal that's broken in the absence of flatpak - but I doubt that.

Source RPM: webkit2-2.30.3-1.mga7.src.rpm => xdg-desktop-portal-1.4.2-1.mga7.src.rpm

Created attachment 12043 [details]
The "New dependencies" list for the package "xdg-desktop-portal".

Attachment 12031 is obsolete: 0 => 1
Attachment 12030 is obsolete: 0 => 1

Should I reopen this bug report (possibly after editing the title)? Or should I create a clean bug report, with corrections to the bug description?

Agreed, let's have Neal take a look.

Resolution: INVALID => (none)
Status: RESOLVED => REOPENED
Assignee: nicolas.salguero => ngompa13
CC: (none) => nicolas.salguero
Summary: libwebkit2gtk4.0_37 / lib64webkit2gtk4.0_37 update introduces unnecessary Flatpak dependencies => xdg-desktop-portal potentially unnecessary flatpak recommends

(In reply to Thierry Vignaud from comment #5)
> Created attachment 12032 [details]
> urpmi --auto-select logs
> 
> Using or not using --no-recommends is not the question.
> An update should not bloat a system in such proportions.
> (see attached logs)

I approve that an update should not add these kinds of dependencies.

The update didn't, they were already there.  They just got pulled in as the new webkit2 required the package that recommends them.

Ping Neal...

Mageia 7 is EOL since July 1st 2021.
There will not have any further bugfix for this release.

You are encouraged to upgrade to Mageia 8 as soon as possible.

@reporter, if this bug still apply with Mageia 8, please let us know it.

@packager, if you work on the Mageia 7 version of your package, please check the Mageia 8 package if issue is also present. In this case, please fix the Mageia 8 version instead.

This bug report will be closed OLD if there is no further notice within 1st September 2021.

(In reply to David Walser from comment #12)
> The update didn't, they were already there.  They just got pulled in as the
> new webkit2 required the package that recommends them.
> 
> Ping Neal...

xdg-desktop-portal is effectively broken if *no* backend is installed. So *a* backend needs to be installed.

Some cleverness would be required to do this more agnostically, but I don't see the harm in having the recommends.

As for the flatpak recommends, it was downgraded from Requires originally in xdg-desktop-portal 1.2.0.

The original depenendency was added to express the need for "/usr/libexec/flatpak-validate-icon" to do icon validation. Since we can't have file dependencies in Mageia while we continue to use URPMI, this information was lost when we imported from Fedora to Mageia.

xdg-desktop-portal-kde requires flatpak, even though it also requires xdg-desktop-portal which recommends flatpak, so that seems wrong.

(In reply to David Walser from comment #16)
> xdg-desktop-portal-kde requires flatpak, even though it also requires
> xdg-desktop-portal which recommends flatpak, so that seems wrong.

Icons don't render without it, as I understand it.

The status of this bug has barely changed since Mageia 7.

xdg-desktop-portal still recommends flatpak, and as David has pointed out, xdg-desktop-portal-kde requires flatpak. In a change from Mageia 7, xdg-desktop-portal-gtk now recommends flatpak as well.

As of Mageia 8, the "Steps to Reproduce" from my first comment are now obsolete, as the bug affects core-release now, not just core-updates.

You can still verify the bug by reading the spec files on Sophie:

# Cauldron

## xdg-desktop-portal-1.8.1-1.mga9.src.rpm

http://sophie.zarb.org/rpms/c6790d06629600b47dcc3ccc66e8e93b/files/2

## xdg-desktop-portal-gtk-1.8.0-2.mga8.src.rpm

http://sophie.zarb.org/rpms/fe1a2d8ca2b5db1a46ffbd7914b2f97a/files/2

## xdg-desktop-portal-kde-5.22.3-1.mga9.src.rpm

http://sophie.zarb.org/rpms/d990e2bea0b04f40318e7bc9191329f6/files/2

# Mageia 8

## xdg-desktop-portal-1.8.0-1.mga8.src.rpm

http://sophie.zarb.org/rpms/fb577d6bfad1644a28fd7fa07ad81709/files/2

## xdg-desktop-portal-gtk-1.8.0-2.mga8.src.rpm

http://sophie.zarb.org/rpms/fe1a2d8ca2b5db1a46ffbd7914b2f97a/files/2

## xdg-desktop-portal-kde-5.20.4-2.mga8.src.rpm

http://sophie.zarb.org/rpms/46691af419506780bdf8b578786861ac/files/2

Version: 7 => Cauldron
Whiteboard: (none) => MGA8TOO

This bug definitely shouldn't be closed as OLD. But if it's unfixable, so long as we continue to use URPMI, then it could be closed as RESOLVED WONTFIX, or set to depend on a URPMI-related bug report.

This is not going to be "fixed", because this is intentional.

Resolution: (none) => WONTFIX
Status: REOPENED => RESOLVED