[AppStream] Dependencies on things in AppStream

[Aleix Pol]

On Sun, Mar 25, 2018 at 9:44 PM, Matthias Klumpp <matthias at tenstral.net> wrote:
> 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
> _______________________________________________
> AppStream mailing list
> AppStream at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/appstream

Wouldn't it make more sense to have the requirements discussion first?
As put here it all looks very random to me.

1) we probably need a way to reach these packages, especially
considering that some restrictions may be arbitrary. What's the
minimum memory required for Apache? Should we stop listing software
that requires bluetooth on devices that don't have it?
2) probably not, but I don't think I've seen that need yet.

Also I was expecting this to include the form factor discussion, I
don't see it mentioned though. Do you expect this spec to tackle it?

Aleix