This is really a question about packaging applications, not a question
about packaging Python.
On Fri, 20 Jan 2023 at 09:48:17 +0000, c.bu...@posteo.jp wrote:
> What is the advantage for Debian users of such a file? Debian doesn't offer
> a "software center".
Yes it does. GNOME Software and KDE Discover are examples of applications
in Debian that use appstream metadata to show a more user-facing view
of the archive than apt does (showing only the interesting end-user-visible
applications, and not showing implementation details like libraries).
> Python projects to offer meta data in form of pyproject.toml or setup.cfg.
> So why should I add another (redundant) meta data file?
One reason is that if software-installation applications like GNOME
Software and KDE Discover were expected to parse Python-specific metadata
for apps that happen to be written in Python, Perl-specific metadata
for apps that happen to be written in Perl, and so on, then that would
scale really badly across all the various languages that exist.
Another reason is that all Python packages, whether they are user-facing
applications (like backintime-qt) or libraries (like dbus-python),
have the Python metadata; but apps like GNOME Software and KDE Discover
mostly only want to show user-facing applications that might appear
in your desktop environment's menus. Having dbus-python appear in a
"software center" app would be pointless and confusing.
> Where is the location of that file? Should it be in the root of the repo or
> is it part of the "/debian" (with control file, etc) folder in that repo?
It should be installed into /usr/share/metainfo in the .deb.
Exactly how it gets there is up to you: the upstream developer of the
package could provide a static XML file in the source package (often
at the top level or in ./data), or the Debian packaging could provide a
static XML file in ./debian, or it could even be generated dynamically at
build-time from metadata in some other representation such as setup.cfg
or pyproject.toml.
This is similar to the way the requirement for a .desktop file is that
it ends up in /usr/share/applications *somehow*, but exactly how it gets
there is up to you, and generating it from a template is one possible
implementation.
If this information is a Debian-specific addition, then please talk to your
upstream about choosing an app ID (in reversed-DNS style, like D-Bus names),
because the app ID should be the same for the Debian package, the Fedora
package, a Flatpak package on Flathub (if it exists), a Snap package (if it
exists), and so on.
In the case of backintime-qt, it seems to use "net.launchpad.backintime"
for D-Bus and polkit, so that would perhaps be a good choice for the
app ID as well.
smcv
