Closed hg42 closed 1 month ago
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.
It's a possibility, but as you mentioned the problem relies on the software packager as well. Doe the info (?
) button helps ?
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...
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.
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?
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)
I guess,
bauh
usesflatpak 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.
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.
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>
...
/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)
I added an issue to the flatpak repo:
the issue is already solved in flatpak:
https://github.com/flatpak/flatpak/issues/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
Hi @hg42 sorry for the late response. Thank you for reporting the issue there (and here as well).
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.
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 toMartin Abente Lahaye
when updated to 2.1.2 (from 2.1.1). I see the same change inflatpak list
: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 likePlatform
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 asorg.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