Hi, due to previous efforts we have a pretty good appdata coverage of apps themselves, but add-ons (plugins, extensions,...) lag far behind. There are dozens of useful GUI app add-ons in Fedora repositories which don't have metadata files and are not exposed to users in GNOME Software. Let's focus on them.
The goal of this iniciative is to have a metadata file for every useful add-on (for a GUI app) that is in Fedora repositories, so that those add-ons appear in app profiles in Software and are easily discoverable and installable for users.
For more information visit https://fedoraproject.org/wiki/Workstation/AddonAppdata
Jiri
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/21/2015 05:36 AM, Jiri Eischmann wrote:
Hi, due to previous efforts we have a pretty good appdata coverage of apps themselves, but add-ons (plugins, extensions,...) lag far behind. There are dozens of useful GUI app add-ons in Fedora repositories which don't have metadata files and are not exposed to users in GNOME Software. Let's focus on them.
The goal of this iniciative is to have a metadata file for every useful add-on (for a GUI app) that is in Fedora repositories, so that those add-ons appear in app profiles in Software and are easily discoverable and installable for users.
For more information visit https://fedoraproject.org/wiki/Workstation/AddonAppdata
I'd love to see more people attempting this. I started on a few of these a while ago, but got disheartened when I got responses like https://bugzilla.redhat.com/show_bug.cgi?id=1267628#c2 when I provided patches.
Richard, is there any way we can carry metadata like this outside of the actual SRPM when maintainers are unwilling to accept the metadata in their package?
On 21 December 2015 at 14:05, Stephen Gallagher sgallagh@redhat.com wrote:
Richard, is there any way we can carry metadata like this outside of the actual SRPM when maintainers are unwilling to accept the metadata in their package?
Unfortunately in the case of upstream being unhelpful, it does have to be in the srpm, either in the .spec file itself (e.g. using <<EOF) or as a referenced source and checked into git. I did try using an external file to collect this a few releases ago, but the package names (or subpackage names) very quickly went out of sync with the extensions and it became really hard to maintain good quality release-specific shared data. I really think the best place is upstream, with downstream in Fedora used where required.
Richard
On Mon, Dec 21, 2015 at 09:05:32AM -0500, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/21/2015 05:36 AM, Jiri Eischmann wrote:
Hi, due to previous efforts we have a pretty good appdata coverage of apps themselves, but add-ons (plugins, extensions,...) lag far behind. There are dozens of useful GUI app add-ons in Fedora repositories which don't have metadata files and are not exposed to users in GNOME Software. Let's focus on them.
The goal of this iniciative is to have a metadata file for every useful add-on (for a GUI app) that is in Fedora repositories, so that those add-ons appear in app profiles in Software and are easily discoverable and installable for users.
For more information visit https://fedoraproject.org/wiki/Workstation/AddonAppdata
I'd love to see more people attempting this. I started on a few of these a while ago, but got disheartened when I got responses like https://bugzilla.redhat.com/show_bug.cgi?id=1267628#c2 when I provided patches.
Richard, is there any way we can carry metadata like this outside of the actual SRPM when maintainers are unwilling to accept the metadata in their package?
I think that this is completely backwards. Either we, as the distribution, decide that appstream is in, and pursue the goal of implementing it, or we don't. We had a vote [https://fedorahosted.org/fpc/ticket/414], appstream metadata was approved as "SHOULD". I get it that maintainers don't want to create appstream metadata on their own, but if somebody did the work, I don't see a good excuse to refuse to put the file in rpm. You add the file, add the two commands to test and install the file, and that's about it. Our ability to implement new technologies which reqire distribution-wide changes hinges on the maintainers following the guidelines and at least passively allowing others to implement the changes.
Zbyszek
On 21 December 2015 at 23:33, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
I think that this is completely backwards. Either we, as the distribution, decide that appstream is in, and pursue the goal of implementing it, or we don't. We had a vote [https://fedorahosted.org/fpc/ticket/414], appstream metadata was approved as "SHOULD". I get it that maintainers don't want to create appstream metadata on their own, but if somebody did the work, I don't see a good excuse to refuse to put the file in rpm.
IMHO, I think you are a pretty bad package (or upstream) maintainer if you refuse to ship a *tiny* extra XML file that makes it easier for users to install your stuff, even if you don't use an application installer yourself.
Richard
desktop@lists.fedoraproject.org