[AppStream] Dependencies on things in AppStream

Matthias Klumpp matthias at tenstral.net
Sun Mar 25 19:44:04 UTC 2018


Hi!

I would like to address the "how can I make my software depend on
$stuff" class of requests in AppStream, most recently a request to
have software require system resources (RAM space / CPU, ...).

So far, I really didn't want to have dependencies in AppStream,
because it adds quite a bit of complexity. Today though, I think the
benefits of having them outweight the costs of adding them.

The dependency system should be as generic as possible, so we can
easily expand it in future for usecases nobody things of right now.

There are multiple classes of things that I see software can depend on
or recommend to be present right now:
 * Hardware (RAM size, disk space, certain devices (TPM, Arduino, ...)
to be present)
 * Software Interfaces and system components (mostly D-Bus interfaces,
a specific kernel version, ...)
 * Other software components (shared libraries, databases, a webbrowser, ...)

I propose to add two relations for declaring a dependency for
software: requires and recommends. A "requires" relation means that
the given dependency *must* be fulfilled, and the software will not
work at all without it. A "recommends" relation means that a
requirement *should* be fulfilled, and the system should do everything
necessary to provide the missing piece, but if that is not possible,
the software will work without the component.

These relations should be reflected in the software center UI, usually
by making software installable or not. There might be exceptions to
that rule though, as sometimes you might want to install software even
if the hardware it requires is not present.

The "requires" and "recommends" relations come with their own tags
which work similar to the already existing "provides" tag.

This is how this would look like in practice:

For dependencies on specific hardware:
```
<recommends>
  <modalias>usb:v1130p0202d*</modalias>
</recommends>
```

Dependencies on system resources:
```
<requires>
  <memory>4GiB</memory>
  <disk_space>10GiB</disk_space>
</requires>
```

System resources and interfaces:
```
<requires>
  <kernel version=">= 4.16">Linux</kernel>
  <dbus type="system">org.freedesktop.login1</dbus>
</requires>
```

Other software:
```
<requires>
  <id version=">= 9.0">org.postgresql.PostgreSQL</id>
</requires>
```

The existing `extends` tag will be treated as having an implicit
`requires` on that particular component-ID in this case (an additional
`requires` relation in addon components could be used to make an addon
work with a specific version of the extended software only).

Open questions:
 1) In case of software shipped by a package manager, should the
AppStream generators on the distro level discard specific dependency
information from upstream metadata, as this is handled by the package
manager already?

 2) People will want to add and/or relations to the items they depend
on (like "this hardware or that hardware", "this interface or that
interface"), so should we add "and" and "or" tags to wrap the existing
tags in, to allow people to reflect those relations? (= do we want
that extra complexity?)

As always, I am interested in feedback before making any invasive change :-)

Cheers,
    Matthias


[1]: https://github.com/ximion/appstream/issues/163 |
https://github.com/ximion/appstream/issues/55


More information about the AppStream mailing list