Future goal:
To be able to publish dev builds under the flathub-beta repo in addition to the normal release builds on flathub. This could expand access and allow for additional users willing to try the dev builds that currently use the flatpak package.
Challenges:
Per https://wiki.jeveassets.org/devbuild
Unless otherwise noted all dev builds have the dev build flag enabled. When the dev build flag is enabled jEveAssets will create a sandbox of you data to keep it safe. This is done by copying the data to the program directory and running portable. That means jEveAssets need to have write permission to program directory. Dev builds also have all program and static data update functionality disabled.
For flatpak packaging the portable mode is unusable as both the program directory and the static data directory are read only with only the user data directory being writable.
We discussed two potential solutions of either having a fixed user data directory under a different name (example ~/.jeveassets-dev or ~/.jeveassets/dev), or a changing user data directory versioned to the dev release (example ~/.jeveassets-dev-810b1 or ~/.jeveassets/dev-810b1). Due to not knowing the future needs of upstream development, such as deciding if user data from beta 1 should be migrated to beta 2 or wiped and reimported from the last stable release, I think its better for jEveAssets developers to make the decisions about when to wipe and reimport user data from the last stable release rather than try to include this logic in the downstream packaging.
Solution 1a:
ex. ~/.jeveassets-dev
The first solution of a singular named directory to store the dev build user data should be straight forward from a packaging prospective. I would include an additional declaration of a data directory in the beta builds only so the directory would always appear empty inside the sandbox on release builds but be populated with user data on beta builds. jEveAssets would need to start tracking the build version that last wrote to the dev user data to handle cases such as a user going through version upgrades like 1.0.0, 1.1.0 beta 1, 1.1.0, 1.2.0, 1.3.0 beta 1. The expected behavior in this example would be that upon first launching 1.3.0 beta 1, .jeveassets would have the most recent data from when the user ran 1.2.0 but .jeveassets-dev would have much older user data from 1.1.0 beta 1 that needs to be ignored and replaced with the 1.2.0 data.
Solution 1b:
ex. ~/.jeveassets/dev
This is very similar to 1a but flatpak packing would not need to add an additional user data directory to track in beta builds. Release versions of jEveAssets could automatically or ask users to wipe the dev build data.
Solution 2a:
ex. ~/.jeveassets-dev-810b1
The second solution of a version specific development build user data directory could be simpler to implement from jEveAssets side but I have concerns and questions I do not currently have answers to for the flatpak packaging. With this solution I would want to be able to do a data cleanup for users when they are not running a development build so they do not end up with an additional full user data directory full of data for each dev build and don't need to preform manual cleanup of the user data. With flatpak packages, I do not have the ability to execute any scripts upon package installation or upgrade. I would only be able to preform the clean up when users launch jEveAssets right before handing over to the jvm.
Solution 2b:
ex. ~/.jeveassets/dev-810b1
Again similar to 2a but this could solve the packaging troubles I forsee coming with 2a.
Next steps:
From a flatpak packaging prospective I only really see a concern with one of the solutions. For solution 2a, there iare some aspects of flatpak packaging I'm not confident about and adding/removing user data directories to the manifest seems like it should rarely be done. Before I can say 2a would be viable I want to preform more research and testing.
Future goal:
To be able to publish dev builds under the flathub-beta repo in addition to the normal release builds on flathub. This could expand access and allow for additional users willing to try the dev builds that currently use the flatpak package.
Challenges:
Per https://wiki.jeveassets.org/devbuild
For flatpak packaging the portable mode is unusable as both the program directory and the static data directory are read only with only the user data directory being writable.
We discussed two potential solutions of either having a fixed user data directory under a different name (example
~/.jeveassets-devor~/.jeveassets/dev), or a changing user data directory versioned to the dev release (example~/.jeveassets-dev-810b1or~/.jeveassets/dev-810b1). Due to not knowing the future needs of upstream development, such as deciding if user data from beta 1 should be migrated to beta 2 or wiped and reimported from the last stable release, I think its better for jEveAssets developers to make the decisions about when to wipe and reimport user data from the last stable release rather than try to include this logic in the downstream packaging.Solution 1a:
ex.
~/.jeveassets-devThe first solution of a singular named directory to store the dev build user data should be straight forward from a packaging prospective. I would include an additional declaration of a data directory in the beta builds only so the directory would always appear empty inside the sandbox on release builds but be populated with user data on beta builds. jEveAssets would need to start tracking the build version that last wrote to the dev user data to handle cases such as a user going through version upgrades like 1.0.0, 1.1.0 beta 1, 1.1.0, 1.2.0, 1.3.0 beta 1. The expected behavior in this example would be that upon first launching 1.3.0 beta 1, .jeveassets would have the most recent data from when the user ran 1.2.0 but .jeveassets-dev would have much older user data from 1.1.0 beta 1 that needs to be ignored and replaced with the 1.2.0 data.
Solution 1b:
ex.
~/.jeveassets/devThis is very similar to 1a but flatpak packing would not need to add an additional user data directory to track in beta builds. Release versions of jEveAssets could automatically or ask users to wipe the dev build data.
Solution 2a:
ex.
~/.jeveassets-dev-810b1The second solution of a version specific development build user data directory could be simpler to implement from jEveAssets side but I have concerns and questions I do not currently have answers to for the flatpak packaging. With this solution I would want to be able to do a data cleanup for users when they are not running a development build so they do not end up with an additional full user data directory full of data for each dev build and don't need to preform manual cleanup of the user data. With flatpak packages, I do not have the ability to execute any scripts upon package installation or upgrade. I would only be able to preform the clean up when users launch jEveAssets right before handing over to the jvm.
Solution 2b:
ex.
~/.jeveassets/dev-810b1Again similar to 2a but this could solve the packaging troubles I forsee coming with 2a.
Next steps:
From a flatpak packaging prospective I only really see a concern with one of the solutions. For solution 2a, there iare some aspects of flatpak packaging I'm not confident about and adding/removing user data directories to the manifest seems like it should rarely be done. Before I can say 2a would be viable I want to preform more research and testing.