08:06:58 <rainemak> #info <Jolla> For apps we are considering something like /opt/apps/<app-name>/
08:07:00 <rainemak> #info <Jolla> application root path that would be out of root partition. …
Some considerations WRT the idea to make the root volume read-only in the long run by suggesting to app developers to install their apps to /opt/apps/<app_name>/usr/bin/<app_name>, /opt/apps/<app_name>/usr/share/<app_name>/ and /opt/apps/<app_name>/usr/share/applications/<app_name>.desktop:
- This is basically unrelated to discussing the size of the root volume. If one sees this as a solution for the tiny root volume size of 2500 MByte, I fully concur with this statement:
08:14:54 <Thaodan> I think /opt/apps is a solution for a problem that is self created that will create more problems - Command line tools, local server services (e.g. OSM Scout Server) etc. (every non-app) provided by third parties still have to be installed / installable in their usual locations on the root volume.
- The content of
/etchas to remain writeable for deploying system-wide configuration changes. - The FHS defines
/etc/optfor configuration files of add-on packages stored in/opt, hence this location also has to be writeable (which it is any way, if the prior point is given). - Creating a separate
/opt/apps/<app_name>/usr/bin/<app_name>and especially/opt/apps/<app_name>/usr/share/<app_name>/for each app will lead to data and / or binaries duplication.
This scheme also prevents providing third party binaries and / or libraries for other apps. - After SailfishOS has adhered to a classic usage of the Filesystem Hierarchy Standard (FHS) for 11 years (i.e. in the way most other Linux distributions do), such a change will be very disruptive, because all badly maintained or unmaintained apps will fail to install when the root volume is switched to read-only.
Side note: I really wonder why Jolla seems to love such disruptive, not backward compatible changes and employs them regularly (the needlessnemo→defaultuserswitch and applying a strict SailJail default configuration to apps which do not bring their own are two other examples of many) which kill old apps, despite the fact that the small app ecosystem always has constituted a major problem for SailfishOS (and continues to do, even more so because many third party developers have left the ship or perform only minimal maintenance of their software due to the structural problems SailfishOS has, especially the long outdated Qt version).
Consequently such a fundamental change would have to be announced loudly and firmly now, in order to perform this change in many years (e.g. for SailfishOS 6 in > 5 years).
Personally, I do not believe following this route is worth the effort, because it “will create more problems”.