Description
I am rather concerned about the current format of the install/uninstall commands as described in the atomic command. As implemented currently it relies on the host OS having a particular runtime available and then gives a script in the container access to the full host root and says "good luck".
Make script runtime/host agnostic
To fix this first concern perhaps have this label spec that there be a defined API on what sort of environment the "install executable" can expect to be operating in, for example having a /media/host-root
mount point, etc. Then the container doesn't need to expect any details about the host and instead the relies on the host to create the correct environment.
Re-evaluate using a script
That said, I think that this whole install/uninstall thing is going to get us into a rather crazy place where containers are going to have to know what type of Linux it is installing to. Instead we could say what are the sorts of things we will need to configure and make them explicit.
For example in the install script in the blog post the command only does a handful of things:
- Puts down some configuration files via templates
- Enables the systemd unit file
Perhaps instead the container should describe those configuration files as metadata and the installer command should pick/choose the files that are appropriate for the host? So there would be a freedesktop.org/systemd/unit-template="[Service]...
label or perhaps a label that is template-linux-host-configuration-dir=/usr/share/app-host-template
.
I propose this because I am a bit skeptical that the API should be defined as a executable running over the root. That seems likely to take us back to a place where every upstream needs to worry about the finicky details of the host OS.