[AppStream] Using AppStream for "Server Applications", Cockpit

[Matthias Klumpp]

Hi!

2017-03-29 17:24 GMT+02:00 Marius Vollmer <marius.vollmer at redhat.com>:
> Hi,
>
> I would like to add a software-center to the Cockpit server manager
>
>   http://cockpit-project.org/
>   https://github.com/cockpit-project/cockpit/wiki/Server-Applications
>
> and one of the ideas is to use AppStream.
>
> I haven't really dug deep into this yet, but let me share the questions
> I have right now:
>
>  - This would probably mean adding type="server-application" to the
>    spec.  Any issues with that?

Not any issues per-se, but we would need to clearly define what a
"server application" actually is, what its metadata requirements would
be and what you would to with it exactly (e.g. will the component-type
be user visible or just be for machines to find missing components,
how will it be represented, etc.).
I have been thinking about adding a component-type "daemon" or
"service" to AppStream for a while, which would cover background
services like webservers, question is whether you could use something
like that for your use-case, or whether a dedicated "server" type is
needed for web-facing stuff.
This will be tricky, I assume (as web server admins will also want to
install services that are *not* web-facing, like MySQL or even stuff
that would be a generic-type component, suhc as Python).

>  - People might balk add installing all of the appstream-data package on
>    a server and then ignoring all of it except the five server apps we
>    actually have.  Can this be split easily?  Fedora could probably have
>    a different appstream-data-server package for the Server variant...

That's an issue of Fedora that I happily direct at Richard :-D
At Debian, only the data the respective frontend requires and only the
data of enabled sources is downloaded and installed.

>  - We would have to consume the metainfo stuff in Cockpit, which likes
>    small servings of JSON.  How would we get a list of
>    type="server-application" components from the available appstream
>    cache?  Would appstream-util help?  Maybe PackageKit?  Maybe mandate
>    YAML and just consume that?

The libappstream library can read & write YAML while AFAIK
libappstream-glib can only read it. At time, the YAML stuff is only
used by Debian, Ubuntu and their derivatives.
While I am not opposed to using YAML in more places, I am not sure
whether I can recommend it, at least at time. This needs more thought.
Is there a reason why you can't use the XML?
Also, be aware that there are two kinds of AppStream metadata,
collection metadata which currently comes as YAML or XML and contains
processed metadata information from multiple components, and metainfo
data that's shipped by upstream projects and that is *always* XML
without any exception.

>  - In this modern world, we will have to have a container story.  If
>    AppStream is the way to go, how do you feel about getting containers
>    in it as well?  I know Flatpak uses AppStream, and I'll make sure
>    that Server Applications via Flatpak will totally be possible, but
>    maybe we also need to include Docker, System Containers, etc to the
>    party.  Has anyone thought about this already?

I don't really know what you mean by that. AppStream, as metadata
format, doesn't care at all which bundling system is used. Maybe going
with it and seeing whether there are any problems when using it with
Docker & Co. would make some sense.
In any case, we want AppStream to work well with containerized and
bundled apps, so this won't be an issue.

It would be awesome to know what exactly you are planning, so can you
maybe give some details on what you want to do with AppStream
specifically?

Cheers,
    Matthias

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