<div dir="ltr"><div><br></div>Yes, that's in the plans for configuration support already.  The idea is to extend snapctl with the ability to introspect exactly which settings have changed since the last successful run of the script, and perhaps which values it used to hold before.<div><br></div><div>For the time being, I suggest not worrying much about that. Just go ahead and implement the semantics you want the user of the snap to experience. Inside the configure hook, check to see if the requested value is already in place and do nothing in that case. This makes the script idempotent, resilient because it ensures the desired state is indeed in place, and also cheap to execute in the common case.</div><div> </div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 1, 2017 at 8:31 AM, Oliver Grawert <span dir="ltr"><<a href="mailto:ogra@ubuntu.com" target="_blank">ogra@ubuntu.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">hi,<br>
<br>
after we recently added a config hook [1] to the core snap it is now<br>
possible to disable ssh if you require [2] ...<br>
<br>
there is a long standing request to do the same for syslog for systems<br>
running from SD card, which is why i looked into trying to extend the<br>
existing configure script for this, which made me notice some issue...<br>
<br>
when you call "snap set core foo=bar", there is no indication at all<br>
for the script which variable changes a value, neither in the shell<br>
environment nor in the argument list.<br>
<br>
the only way to get your value is to call snapctl for every existing<br>
variable [3]. since you dont know what specific variable was requested<br>
to change the only way to reliably write it is to write *all* existing<br>
variables ... <br>
<br>
now, if you package something with a more complex config that you want<br>
completely handled via snap config this gets ugly very fast... imagine<br>
something like postfix with can potentially have 100s of config<br>
options. instead of atomically changing a single option you will<br>
regenerate the full config from scratch. this takes a lot longer,<br>
bringing the risk of a completely broken config in case of a power<br>
loss, beyond resulting an an awful config hook script with a large<br>
block of "snapctl get" calls at the top.<br>
<br>
can we extend the config hook implementation minimally so a "snap set<br>
core foo=bar" would at least have something like "SNAP_OPTION=foo" in<br>
the environment that the generating script or binary could read to<br>
avoid the unnecessary processing or would that break some design<br>
concept ?<br>
<br>
ciao<br>
        oli<br>
<br>
[1] <a href="http://bazaar.launchpad.net/~snappy-dev/core-snap/trunk/view/head:/
hooks/configure" rel="noreferrer" target="_blank">http://bazaar.launchpad.<wbr>net/~snappy-dev/core-snap/<wbr>trunk/view/head:/<br>
hooks/configure</a><br>
[2] <a href="https://github.com/CanonicalLtd/ubuntu-core-docs/blob/master/en/ref
erence/core-configuration.md" rel="noreferrer" target="_blank">https://github.com/<wbr>CanonicalLtd/ubuntu-core-docs/<wbr>blob/master/en/ref<br>
erence/core-configuration.md</a><br>
[3] <a href="https://github.com/snapcore/snapd/wiki/hooks" rel="noreferrer" target="_blank">https://github.com/<wbr>snapcore/snapd/wiki/hooks</a><br>--<br>
Snapcraft mailing list<br>
<a href="mailto:Snapcraft@lists.snapcraft.io">Snapcraft@lists.snapcraft.io</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/snapcraft" rel="noreferrer" target="_blank">https://lists.ubuntu.com/<wbr>mailman/listinfo/snapcraft</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">gustavo @ <a href="http://niemeyer.net" target="_blank">http://niemeyer.net</a></div>
</div>