Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.maint.python > #14852 > unrolled thread
| Started by | c.buhtz@posteo.jp |
|---|---|
| First post | 2023-01-20 10:50 +0100 |
| Last post | 2023-01-20 15:50 +0100 |
| Articles | 3 — 2 participants |
Back to article view | Back to linux.debian.maint.python
What is this about the metainfo-file? c.buhtz@posteo.jp - 2023-01-20 10:50 +0100
Re: What is this about the metainfo-file? c.buhtz@posteo.jp - 2023-01-20 11:40 +0100
Re: What is this about the metainfo-file? Simon McVittie <smcv@debian.org> - 2023-01-20 15:50 +0100
| From | c.buhtz@posteo.jp |
|---|---|
| Date | 2023-01-20 10:50 +0100 |
| Subject | What is this about the metainfo-file? |
| Message-ID | <FPWc1-1HFv-1@gated-at.bofh.it> |
Hello, I try to understand the "metainfo" file I was pointed to by an "AppStream hint". https://appstream.debian.org/sid/main/issues/backintime-qt.html There are some links pointing to freedesktop.org. There is also appstream.debian.org. I read that and got the keys of that concept. But I want to know how this is related to Debian especially Python projects. Python projects to offer meta data in form of pyproject.toml or setup.cfg. So why should I add another (redundant) meta data file? 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? What is the advantage for Debian users of such a file? Debian doesn't offer a "software center". ;) Kind Christian
[toc] | [next] | [standalone]
| From | c.buhtz@posteo.jp |
|---|---|
| Date | 2023-01-20 11:40 +0100 |
| Message-ID | <FPWYp-1Icb-5@gated-at.bofh.it> |
| In reply to | #14852 |
Please let me add one additional thought. It seems easy to me to extract he meta data (via importlib.metadata) from a python project that suites to the python packaging standards (providing a pyproject.toml, setup.cfg and things like that). In that case it seems easy to have a debian-python-packaging-magic-tool on your site that will extract the data, generate a metainfo file and add it to the debian package. Kind Christian
[toc] | [prev] | [next] | [standalone]
| From | Simon McVittie <smcv@debian.org> |
|---|---|
| Date | 2023-01-20 15:50 +0100 |
| Message-ID | <FQ0Sl-1KCR-15@gated-at.bofh.it> |
| In reply to | #14852 |
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.buhtz@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
[toc] | [prev] | [standalone]
Back to top | Article view | linux.debian.maint.python
csiph-web