There has been a push in systemd to distribute software as signed disk images rather than signed files.
I think this could be a good idea, but there are some issues that I think UAPI.9 could solve, especially when it comes to large deployments and desktop users.
Specifically, if third-party vendor software is distributed as a sysext, then the third-party vendor is the one to decide which directories the software is installed in, not the OS vendor or local administrator, and so the guidelines need to be tailored to the local administrator's needs.
Use-cases
Additional vendor software
This is the primary use of third-party vendor software, which is that a local administrator treats it like first-party software.
The package then installs integration files into /usr/bin/, /usr/share/, etc. and puts their private files in /usr/lib/<pkgname>/.
There only needs to be one version "activated" at a time, so the version can just exist in the sysext file.
Separate vendor software
A single piece of software may be installed on many different distributions and thus does not want to assume that /usr/bin/<pkgname> is not somehow an important binary.
It then might choose to install their files into /usr/local/ instead to avoid clashes with the OS vendor and let the local administrator handle naming clashes.
Optional software
In a Linux environment at a university, there must be many versions of the same software available in a public directory.
Having each user install software to their home directory doesn't work, since they are limited in size, and installing to global directories such as /usr/bin/ is not a good choice as different users have different version requirements.
In this scenario, a third-party vendor should distribute their software entirely in /usr/lib/<name>-<version>/ or /usr/lib/<name>/<version>/ and allow the local administrator to handle the creation of symlinks in /usr/bin/ or /usr/share/ as desired. Users who need to use a specific version of the software can reference the full path in /usr/lib/.
Recommendation(s)
systemd-sysext could add support for "partial activation", where only the files in specific directories (ex. /usr/lib/) participate in the merge.
If this feature is added, then a recommended sysext creation strategy could be to store all files in /usr/lib/<name>/, and to distribute symlinks in the other /usr/ subdirectories to allow for both activation methods.
The other option is to explicitly discount the second software installation method, and/or to say that support for multiple versions of the same software installed at the same time is out-of-scope of UAPI.9.
There has been a push in systemd to distribute software as signed disk images rather than signed files.
I think this could be a good idea, but there are some issues that I think UAPI.9 could solve, especially when it comes to large deployments and desktop users.
Specifically, if third-party vendor software is distributed as a
sysext, then the third-party vendor is the one to decide which directories the software is installed in, not the OS vendor or local administrator, and so the guidelines need to be tailored to the local administrator's needs.Use-cases
Additional vendor software
This is the primary use of third-party vendor software, which is that a local administrator treats it like first-party software.
The package then installs integration files into
/usr/bin/,/usr/share/, etc. and puts their private files in/usr/lib/<pkgname>/.There only needs to be one version "activated" at a time, so the version can just exist in the sysext file.
Separate vendor software
A single piece of software may be installed on many different distributions and thus does not want to assume that
/usr/bin/<pkgname>is not somehow an important binary.It then might choose to install their files into
/usr/local/instead to avoid clashes with the OS vendor and let the local administrator handle naming clashes.Optional software
In a Linux environment at a university, there must be many versions of the same software available in a public directory.
Having each user install software to their home directory doesn't work, since they are limited in size, and installing to global directories such as
/usr/bin/is not a good choice as different users have different version requirements.In this scenario, a third-party vendor should distribute their software entirely in
/usr/lib/<name>-<version>/or/usr/lib/<name>/<version>/and allow the local administrator to handle the creation of symlinks in/usr/bin/or/usr/share/as desired. Users who need to use a specific version of the software can reference the full path in/usr/lib/.Recommendation(s)
systemd-sysextcould add support for "partial activation", where only the files in specific directories (ex./usr/lib/) participate in the merge.If this feature is added, then a recommended
sysextcreation strategy could be to store all files in/usr/lib/<name>/, and to distribute symlinks in the other/usr/subdirectories to allow for both activation methods.The other option is to explicitly discount the second software installation method, and/or to say that support for multiple versions of the same software installed at the same time is out-of-scope of UAPI.9.