names of flatpak packages are replaced by author

[hg42]

Describe the bug

The name column of many updated flatpaks now contains the author.

I think, it's not really a bug of bauh, but the strategy to determine a name seems to rely on something undefined.

I"m not sure why this changes, but it's happening with lots of flatpak packages.

E.g. the Flatseal package changed it's name to Martin Abente Lahaye when updated to 2.1.2 (from 2.1.1).
I see the same change in flatpak list:

Name                                            Application ID                                      Version                Branch            Installation
Adobe Reader                                    com.adobe.Reader                                    9.5.5                  stable            system
DIY Layout Creator                              com.diy_fever.DIYLayoutCreator                      4.37.0                 stable            system
DSView                                          com.dreamsourcelab.DSView                           1.3.0                  stable            system
Giada Developers                                com.giadamusic.Giada                                1.0.0                  stable            system
Gittyup                                         com.github.Murmele.Gittyup                          v1.3.0                 stable            system
Marker                                          com.github.fabiocolacio.marker                      2023.05.02             stable            system
Julián Unrrein                                  com.github.junrrein.PDFSlicer                       1.8.8                  stable            system
Pods                                            com.github.marhkb.Pods                              2.0.1                  stable            system
MarkText                                        com.github.marktext.marktext                        0.17.1                 stable            system
Minder                                          com.github.phase1geo.minder                         1.16.3                 stable            system
Martin Abente Lahaye                            com.github.tchx84.Flatseal                          2.1.2                  stable            system
Oomox theme designer                            com.github.themix_project.Oomox                     1.15.1                 stable            system
Wellington Wallace                              com.github.wwmm.easyeffects                         7.1.6                  stable            system

Unfortunately the ID isn't structured consistently.
Usually the package name is the last one, but there are packages like org.gnome.Platform where this is not exactly the case.
At least something like Platform is not a good name, gnome would be the better name here.
Actually only the full ID would be sufficient for all cases, because even if the last part is the usual package name, it could be duplicated, e.g. for a different platform.
e.g. org.gnome.Platform.XXX could also exist as org.kde.Platform.XXX or similar.

While I see this as a problem of those packages (or how they are created), it's difficult to see which package it is, if I don't know the author and the description is not sufficient.

Software Environment

bauh version: 0.10.7
O.S: Debian
Installation method: appimage

[hg42]

for a complete list of IDs, bauh could check if the name is unique and take one more part otherwise, etc.

Maybe some common parts (like com.) could simply be deleted, but they would be stripped anyways, unless they are necessary, e.g. if there is the same package with com. and org. or country prefix like de..

The above example org.gnome.Platform.XXX vs. org.kde.Platform.XXX would be stripped to gnome.Platform.XXX and kde.Platform.XXX.
Some explicit knowledge could be accepted, e.g. xxx.Platform could be shortend to xxx in almost all cases (which can also be achieved by stripping .Platform in the result, if still results in unique names).
There are also some other patterns, like xxx.xxx or com.github., but these would also be automatically stripped with the unique end strategy.

[vinifmor]

It's a possibility, but as you mentioned the problem relies on the software packager as well. Doe the info (?) button helps ?

[hg42]

in the info is no field providing an app name (apart from the Id).
The title of the info window should be the app name, but is user name instead.
For apps like 64Gram, there is no 64Gram anywhere, the name of the app is now "Husky" and the id is io.github.tdesktop_x64.TDesktop.
TDesktop is not very helpful, but still more than Husky.
In fact, today while updating apps, I thought, what the hell is Husky, because it does not look like a user. It took a while until I realized, that it's 64Gram.

It's interesting, that flatpak search telegram still finds:
64Gram Desktop Unofficial desktop version of Telegram messaging app io.github.tdesktop_x64.TDesktop 1.1.18 stable flathub

But flatpak list shows:
Husky io.github.tdesktop_x64.TDesktop 1.1.18 stable system
and it claims, the first field is Name in the header line.

I would guess, the index is not up to date, but the version is 1.1.18 and it was Husky with 1.1.16, so enough time...

[hg42]

surprisingly, flatpak info outputs:

Husky - Unofficial desktop version of Telegram messaging app

          ID: io.github.tdesktop_x64.TDesktop
         Ref: app/io.github.tdesktop_x64.TDesktop/x86_64/stable
        Arch: x86_64
      Branch: stable
     Version: 1.1.18
     License: GPL-3.0
      Origin: flathub
  Collection: org.flathub.Stable
Installation: system
   Installed: 235.6 MB
     Runtime: org.freedesktop.Platform/x86_64/23.08
         Sdk: org.freedesktop.Sdk/x86_64/23.08

      Commit: 303bf90a920d10b8ff39470d6a83b581ade9714ff96fecf810082c1866f9d1a9
      Parent: ce55fd6f7df059ef2ed228303bca6ab224d914b6e2d70855a4f138ffd5578132
     Subject: Update Qt patches to desktop-app/patches@f81dfc6 (d4f4f625)
        Date: 2024-04-18 23:16:13 +0000

but flatpak remote-info flathub io.github.tdesktop_x64.TDesktop shows:

64Gram Desktop - Unofficial desktop version of Telegram messaging app

        ID: io.github.tdesktop_x64.TDesktop
       Ref: app/io.github.tdesktop_x64.TDesktop/x86_64/stable
      Arch: x86_64
    Branch: stable
   Version: 1.1.18
   License: GPL-3.0
Collection: org.flathub.Stable
  Download: 89.3 MB
 Installed: 235.6 MB
   Runtime: org.freedesktop.Platform/x86_64/23.08
       Sdk: org.freedesktop.Sdk/x86_64/23.08

    Commit: 303bf90a920d10b8ff39470d6a83b581ade9714ff96fecf810082c1866f9d1a9
    Parent: ce55fd6f7df059ef2ed228303bca6ab224d914b6e2d70855a4f138ffd5578132
   Subject: Update Qt patches to desktop-app/patches@f81dfc6 (d4f4f625)
      Date: 2024-04-18 23:16:13 +0000

so all fields have the same value (for the same field), but the title is constructed differently.

[hg42]

if I search 64gram in bauh, I get the Husky entry...
I wonder why? it seems the 64gram is still found in the data?
I guess, bauh uses flatpak search and then shows the data from the installed package?

[vinifmor]

exactly... bauh tries to delegate to the backend whenever possible (see https://github.com/vinifmor/bauh/blob/master/bauh/gems/flatpak/flatpak.py#L330). As you suggested: bauh could check if there are duplicated names among the results (if so, display the id instead to prevent confusion)

[hg42]

I guess, bauh uses flatpak search and then shows the data from the installed package?

the main point in my sentence was the difference between info from "search" and "installed", only the search result contains the package label.

My idea was, bauh could use the search result instead of the info from the installed package.
This is no problem when searching, I guess both are available at that point.
But when showing the installed packages, the search result isn't available.
bauh could eventually store that as an alias.

But the correct way would be to fix it on flatpak side... I guess at some point either the search results will also switch... or the installed packages will switch back.

[hg42]

on my system I have 57 flatpak app packages

% flatpak list --app | wc
     57     327    3367

I count 25 packages that have the developer_name as the name in info and list commands (I think I missed one of them).

This command lists the names for these packages:

grep '<name>' /var/lib/flatpak/app/**/export/share/metainfo/*.metainfo.xml

[EDIT: there were 27 lines, but these come from 25 files, because <name> can be inside <developer>]

the same file seems to be located inside the installation:

package=io.github.tdesktop_x64.TDesktop
flatpak run --command='cat' $package /app/share/metainfo/$package.metainfo.xml | xmlstarlet sel -t -v '/component/name'

Maybe it could contain multiple components, I guess then the type=desktop(-application) component would be the one to choose.

A command like:

for f in /var/lib/flatpak/app/**/export/share/metainfo/*.metainfo.xml; do if grep '<name>' $f; then xmlstarlet sel -t -v '/component/name' $f; echo; fi; done

shows a lot more output, because the name may be given for each supported language.

The *.desktop file could also be a good candidate. It should contain the name relevant to a user.

And some of the metainfos also contain the developers.

[hg42]

the path must be exact, because name can also be an element below another one:

  <?xml version="1.0" encoding="UTF-8"?>
  <component type="desktop-application">
    <id>org.freefilesync.FreeFileSync.desktop</id>
    <metadata_license>CC0-1.0</metadata_license>
    <project_license>GPL-3.0</project_license>
    <name>FreeFileSync</name>
    <summary>Visual folder comparison and synchronization</summary>
    <developer id="freefilesync.org">
      <name>Zenju</name>
    </developer>
    ...

[hg42]

/var/lib/flatpak/exports/share/applications/ contains all the desktop entries...

and this lists all names:
grep -m 1 '^Name=' /var/lib/flatpak/exports/share/applications/*.desktop

assuming the first Name entry is the main entry.
There are more for other actions:

Name=PeaZip
Name=PeaZip, add to archive
Name=PeaZip, extract archive(s)
Name=PeaZip, extract here
Name=PeaZip, extract here (smart new folder)

[hg42]

I added an issue to the flatpak repo:

flatpak/flatpak#5784

[hg42]

the issue is already solved in flatpak:

flatpak/flatpak#5700

From my flatpak issue:

In the 1.15.x branch, this should be fixed in 1.15.7 and up, but it seems that the name that was already stored for apps that were installed while using an affected version of Flatpak remains wrong even after Flatpak is upgraded. As far as I'm aware, reinstalling or upgrading the affected apps resolves this, so it should solve itself "naturally" over time.

In the 1.14.x branch, this is fixed in 1.14.6, with the same caveats. I am waiting for permission from the Debian stable release managers to get this fixed in bookworm."

My tests confirmed that it is dependent on the flatpak version at installation time of a package.
Reinstalling a package (e.g. uninstall+install or downgrade+upgrade) fixes the name.
It's basically possible to reinstall via command line, but it's not really easy... I can go into details about the shell commands if someone is interested

[vinifmor]

Hi @hg42 sorry for the late response. Thank you for reporting the issue there (and here as well).

[hg42]

LOL, no response was necessary :-) The whole issue was kind of vaporware.
Actually, I waited quite a long time, to see if it resolves by itself, but instead it continued to grow.
As the effect and solution propagate through two layers (flatpak+bauh) plus they only work incrementally, it needs much longer.