With latest changes auto-cpufreq uses hostnamectl. I noticed if I build and install my snap using --devmode that this functionality will work as expected, however, if I run it in strict confined it will fail to work as expected.
These are the plugs I currently use and from my research I also need hostname-control interface to be able to use this as part of this Snap’s strict confinement?
Hence, could you please approve auto-connect for this interface?
is there any rason to not use the quasi standard of calling dmidecode --string chassis-type (which you would indeed need to ship via a stage-package in your snap to make sure it is available (but this is similar for hostanmectl too i guess since there is no guarantee the host has this command around)) ?
feels a bit odd to use a tool created to manipulate the hostname to determine hardware data …
This particular change was made by a contributor, which I deemed as a good solution which I merged with master. Since this tool besides Snap also, has an installer for pretty much any distros, as well as AUR package. Using dmidecode also requires me to make sure it’s installed as a dependency on all those systems. Hence why hostnamectl made sense as it’s available everywhere by default with systemd.
I’ve requested changes to be made as part of original commit which introduced these changes, because I do believe dmidecode would make more sense. Will keep you updated.
update: switched to dmidecode, problem solved. Thank you for your input and suggestion @ogra
