search

atweiden / zramen

Manage zram swap space
The Unlicense
20 stars 4 forks source link

Ability to use a config file by default #8

Closed migmolrod closed 2 months ago

migmolrod commented 2 months ago

After reading PR #4 I got an idea to allow service configuration that persists across package updates, but it's up to you to implement it or not, @atweiden . There are actually two options.

Option A

At first my idea was to only delegate that responsibility to each package (for example, in #4 we were talking about artix and it's subpackages for zramen: zramen-s6, zramen-dinit, zramen-openrc and zramen-runit).

But what if we change zramen in this repo with these two steps:

  1. add a param [-c|--config-file] <config-file-path> so users are able to specify a complete config file instead of having to pass every single param one by one (-a for algo, -s for size, -p for prio and so on). The users can specify a config file that is kept even if zramen is updated.
  2. [optional] include an easy check for a default config file in the zramen script. For example, when I asked ChatGPT how to correctly install and use zramen with dinit, it suggested to export some variables in the /etc/default/zramen file. Maybe we can use that. I think ChatGPT completely made up that file, "copying" it from the zramd package.

Then the package mantainers for the zramen package itself could decide to copy your sv/zramen/conf file to /etc/default/zramen in the first place if they decide. The /etc/default/zramen config file would be overriden on package updates but that's ok (I think that's the purpose of /etc/default). The point is to have a default config (from your package) that users and mantainers can have as template for their own. And then use that new -c option to specify a custom config file.

Finally, package mantainers for any of those subpackages I mentioned (for s6, dinit, openrc and runit) can handle it differently. For example, in dinit we have an /etc/dinit.d/config folder to store config files for services. The PKGBUILD of zramen-dinit could copy the file in that folder only if it does not exist already, to be sure user configuration is not overriden on package updates. And in the custom script, use the new -c option, as I said.

Option B

Would be to skip step 1 above and only do step 2, deciding another location for the config file that makes it clear it shouldn't be overwritten on package updates. For example, /etc/zramen.conf or /etc/zramen.d/config, something like that.

Then the package mantainers for zramen package could copy your sv/zramen/conf file to the decided location, but this time only if it doesn't already exists (to avoid losing user custom configurations).

Finally, package mantainers for any of the subpackages can decide to use a custom location for the config file or use the default location from zramen.

I prefer option B. Looks more straightforward, less convoluted.

I'll try to do a couple PRs for this when I come back home to see a list of all changes and the real scope of each option.

atweiden commented 2 months ago

I’m marking this wontfix. Parsing a config file is beyond the scope of zramen’s intended functionality. I wouldn’t want to implement that in bash.