The generator cannot read symlinks on Debian / Ubuntu

[sidt4]

From https://appstream.debian.org/sid/main/issues/firefox.html:

Errors

    icon-not-found
    The icon 'firefox' was not found in the archive. This issue can have multiple reasons:
        The icon is not present in the archive.
        The icon is in a wrong directory.
        The icon is not available in a suitable size (at least 64x64px)
        On Debian and Ubuntu, the icon is a symlink. The generator cannot read symlinks on these distributions - make the icon a real file.
    To make the icon easier to find, place it in /usr/share/icons/hicolor/<size>/apps and ensure the Icon= value of the .desktop file is set correctly.

On my system, where firefox is installed from debian main repo:

$ ls -l /usr/share/icons/hicolor/64x64/apps/firefox.png
lrwxrwxrwx 1 root root 62 Aug  2 23:39 /usr/share/icons/hicolor/64x64/apps/firefox.png -> ../../../../firefox/browser/chrome/icons/default/default64.png

Why is there a symlink restriction in Debian / Ubuntu ?

Also refer: https://gitlab.gnome.org/GNOME/gnome-software/-/issues/2314

[ximion]

This will not be fixed. Symlinks are not mentioned in deb package index files (md5sum files, symlinks do not have an md5sum, so no wonder they aren't there) or Contents lists, so we would need to unpack every single package in the whole archive which would absolutely tank performance of the generator and use a huge amount of resources.

[ximion]

Furthermore, symlinks may even point to stuff in other packages (the case for Firefox and others), which is even worse because that would mean the generator would now also need to learn about dependencies, build a dependency graph and not only explode the package containing the symlink, but also every single thing in the dependency chain to find its actual target.

That is so insanely impractical, and the amount of symlinks for this is so rare (last time I checked it was less than 10 packages) that it really does not warrant the effort and performance impact on the whole system. It is much easier to fix the packages, and that's what the warning emitted by asgen is for, and why Debian has guidelines for this: https://wiki.debian.org/AppStream/Guidelines

[ximion]

You are very welcome to find someone from the Debian Mozilla team to finally merge the respective patch: https://salsa.debian.org/mozilla-team/firefox/-/merge_requests/5

[sidt4]

You are very welcome to find someone from the Debian Mozilla team to finally merge the respective patch: https://salsa.debian.org/mozilla-team/firefox/-/merge_requests/5

Any idea why this MR is done in firefox downstream and not upstream ?

[sidt4]

From https://wiki.debian.org/AppStream/Guidelines

Writing a metainfo file

If you provide a metainfo file its information will be preferred over that in the .desktop file.

The quickstart guide tells you how to write an appstream metainfo file. These should be submitted and shipped by upstream, not kept locally in Debian packages.

[sidt4]

Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1851524

[ximion]

Any idea why this MR is done in firefox downstream and not upstream ?

No, presumably this was tried? Mozilla must be maintaining the data already for their Flatpak builds, but AFAIK it's also kept separate there...

[ximion]

Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1851524

Thanks - the icon-linking is Debian's doing though: https://salsa.debian.org/mozilla-team/firefox/-/blob/release/master/debian/browser.links.in Then again, I have no idea why Firefox doesn't install that stuff in the right location in the first place...

[sidt4]

I've updated the mozilla bug.