[AppStream] Services

[Matthias Klumpp]

2017-05-09 10:00 GMT+02:00 Marius Vollmer <marius.vollmer at redhat.com>:
> Hi,
>
> to make AppStream more useful for servers, I would like to propose a new
> component type "service".

Yay!

> It could look like this:
>
>     <component type="service">
>       <id>org.cockpit-project.mock.app-service</id>
>       <metadata_license>CC0-1.0</metadata_license>
>       <name>Demo Service</name>
>       <icon type="cached" height="64" width="64">app-service.png</icon>

The "cached" icon type is not valid for metainfo files, it would
either have to be "stock" or "local" (or "remote"), because the cache
is exclusively generated by the AppStream collection metadata
generator on the distribution's server.
Just a nitpick though ^^
Using "stock" would mean that services need to ship an icon in
/usr/share/icons, while "local" would require an absolute path to the
icon on the filesystem.
I guess the default state for many apps would be to not have an icon at all.

>       <summary>
>         A demo systemd service
>       </summary>
>       <description>
>         ...
>       </description>
>       <launchable type="service">demo</launchable>
>     </component>
>
> I have used the new "launchable" tag instead of "provides" since I am
> interested in constructing a user interface for a component, and not in
> automatically finding missing services.  Does that make sense?

Yes, that's what the launchable tag was designed for :-)
Using it here is way better than adding a new provides type.

> I don't think we need to mention anything about specific init facilities
> in the metainfo.  For example, we don't need to say that a component
> contains a systemd unit.  It should be enough to give a name that works
> with the init facility of the OS.

Jup - systemd handles SysVInit scripts without issues anyway, so I
also do not see a need to specify the init system here.

> Proposed spec additions below.  I can do the work of marking this up
> properly once we get closer to consensus.
>
> # Service
>
> ## Introduction
>
> A service component is any software that is started and supervised by
> the Operating System "init" facility, such as systemd.
>
> [...]
>
> ## File specification
>
> [...]
>
>   <launchable/>
>
>   At least one launchable element with type "service" must be present.
>   The value is a name that can be used with the OS init facility to
>   start/stop and monitor the service.
>
>   For example, of the init facility is systemd, the value is the name of
>   a systemd unit.
>
>   If more than one launchable element with type "service" is present, a
>   UI is expected to let the user manage all services.  Thus multiple
>   launchables are not alternatives to start the same service, but the
>   component does contain multiple services that might all need to be
>   started.
>
>   Only those services should be listed as launchables that the user is
>   actually expected to start and stop manually.  Services that are
>   started/stopped indirectly via dependencies of other services should
>   not be listed.
>
>   For systemd units, the services listed as launchables are expected to
>   support enabling and disabling.
>
> [...]

Actually, this looks pretty good to me!

Cheers,
    Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/