[pkg-wine-party] Bug#848839: AppStream metadata for Wine

Matthias Klumpp mak at debian.org
Thu Jan 12 18:40:03 UTC 2017


Hi!

2017-01-12 18:51 GMT+01:00 Jens Reyer <jre.winesim at gmail.com>:
> Hi Matthias,
>
> I'm working on an AppStream file for Wine (winehq.org), mainly to have
> it shown in the Software Center. I'm mostly done by now (initial version
> attached, icons are not finished yet, and stuff in there is still static).
>
> Now I got a few questions.  I hope you can help me, or tell me a better
> place to ask.
>
>
> Background:
>
> I assume you generally know Wine.
>
> There is a wine.desktop, but for other reasons we only ship it as an
> example.  Still, other distros probably install it.  However that
> .desktop file has "NoDisplay=true" so afaik it wouldn't be used for
> AppStream anyway.

That's not necessarily the case - if a metainfo file is provided, a
NoDisplay field is ignored.

> Wine itself is not a graphical application, but of course it can be used
> to run such.  On its own it has a few graphical helper applications
> (winecfg, notepad, ...), but also provides e.g. wineconsole.
>
>
> 1.) Component type "desktop" or "generic"?
>
> Which one should we use, given above described background?
> Is "generic" visible in the software center?

KDE Discover shows generic components, while GNOME Software does not.
So the answer is "it depends".

> Does "generic" accept tags which are defined only for "desktop"?

Yes.
"desktop" btw is an outdated name, to describe applications you can
pick the component types "desktop-application" and
"console-application", while KDE Discover shows both and GNOME
Software only shows desktop apps (rationale being that users who use
GS can't deal with console applications).

>
> 2.) License
>
> I'd like to stick with the upstream license LGPL-2.1+.
> Does this work for AppStream purposes?
> Alternatively I'm thinking about e.g. "LGPL2.1+ or MIT".

That's fine. For the project_license tag generally everything license
is allowed.
For the metadata itself (metadata_license tag), we need a permissive
license to merge metadata together in one big stream of data without
violating a license. I suggest using the FSFAP license for that (see
https://spdx.org/licenses/FSFAP.html )

> 3.) Which "id" should we use?
>
> Stretch will ship 2 versions of Wine:
>
> - src:wine which tracks upstreams stable branch
> - src:wine-development which tracks the development branch
>
> I thought about ignoring the desktop file completely, and use for
> upstream and our src:wine:
>
>   <id>org.winehq.wine</id>
>   <name>Wine</name>
>
> Then I'd expand the id and change the name for src:wine-development to
>
>   <id>org.winehq.wine.development</id>
>   <name>Wine (development version)</name>

In this particular case, I think you are correct, not using the
.desktop file is probably best. In case you don't use it, you need to
set an <icon =type=stock"> tag in the metainfo file though (at least
for desktop-application type apps).
The IDs and names make a lot of sense to me :)

For the example file:
The validation fails with:

Could not parse XML data: Entity: line 2: parser error : Start tag expected, '<'
    not found
    <!-- Copyright 2017 Jens Reyer <jre.winesim at gmail.com> -->
    ^

I assume this is due to the < being some other character, because
rewriting the header worked well.
There were also a couple of & signs in the XML which need to be &
escaped for XML.

The icon types "cached", "remote" and "local" are not allowed in
metainfo files (reminds me to add a validator test for that), only
"stock" is fine.

When I validate again after fixing the issues, I get:

W - org.winehq.wine.development.appdata.xml:org.winehq.wine.development:7
    The metadata itself does not seem to be licensed under a permissive license.
    Please license the data under a permissive license, like FSFAP,
CC-0-1.0 or MIT to
    allow distributors to include it in mixed data collections without
the risk of
    license violations due to mutually incompatible licenses.

The file is still full of control characters though (open in with vim
to see them...).
Otherwise the file looks fine, a screenshot might be nice though.
(Edited file is attached)

Cheers,
    Matthias

P.S: Let me know when an updated Wine is uploaded, this will be the
only app I know which does not use the metainfo file to augment a
.desktop file, and I am curious to see if the file is handled
correctly.

-- 
I welcome VSRE emails. See http://vsre.info/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: org.winehq.wine.development.appdata.xml
Type: text/xml
Size: 1923 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-wine-party/attachments/20170112/18bb6bd0/attachment.xml>


More information about the pkg-wine-party mailing list