The ultimate ZRAM module destiny question

[tbzatek]

trafficstars

The zram module starts showing its age and we should decide the next steps: fix it or drop it.

Problems:

• ~~systemd only, no configure check whether the target system really runs systemd~~
• ~~PACKAGE_ZRAMCONF_DIR define mismatches the hardcoded [email protected]'s EnvironmentFile path, essentially breaking the overall functionality (to be fixed soon)~~
• no awareness of foreign zram management projects and existing zram block devices, while still offering their management
• ~~the /usr/lib/modules-load.d/zram.conf and /usr/lib/modprobe.d/zram.conf files carry no indication of being created by UDisks~~

Nowadays there are several widely used projects offering some kind of zram device management, such as zram-generator, zram-init and zramctl from util-linux apart from custom-coded user scripts. Each one uses slightly different methods, works over different set of config files and can mess up with existing zram block devices created some other way.

One way to go forward could be to add awareness of foreign devices and either present a nice error message or even add full management support.

[tbzatek]

TODO: When overwriting existing config files, shall we first check that it was created by us, e.g. by a comment block and deny any change operation when it's not?