<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Le 01/02/2017 à 13:05, Gustavo Niemeyer
a écrit :<br>
</div>
<blockquote
cite="mid:CANySw1=fHaVoZOEVJOWtZyjfUoiB-KBvth9XadtgUZ9c1Yfv7w@mail.gmail.com"
type="cite">
<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>
</blockquote>
<br>
If someone is interested, I have implemented this kind of idempotent
configure hook example. It can be found at
<a class="moz-txt-link-freetext" href="https://github.com/ubuntu/snow-on-me-snap/blob/master/meta/hooks/configure">https://github.com/ubuntu/snow-on-me-snap/blob/master/meta/hooks/configure</a>
as part of the christmas snap demo.<br>
It features:<br>
- support key=value formatting<br>
- ignoring, but not erasing unknown keys, comment lines, empty ones.<br>
- preserving formatting and ordering, even when changing an existing
key.<br>
- only snap set arguments will be modified if a value is set. If the
value assigned to it is empty, removing the key line<br>
- new elements not present in existing configuration file are simply
appended.<br>
<br>
Supporting new keys (like here "foo") is just a matter of adding:<br>
update_opt_in_config foo<br>
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
<br>
at the end of the file.<br>
<br>
I hope this helps! (note that the issue is still "what's the
supported keys for this snap?")<br>
Cheers,<br>
Didier<br>
<br>
<blockquote
cite="mid:CANySw1=fHaVoZOEVJOWtZyjfUoiB-KBvth9XadtgUZ9c1Yfv7w@mail.gmail.com"
type="cite">
<div dir="ltr">
<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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="http://bazaar.launchpad.net/%7Esnappy-dev/core-snap/trunk/view/head:/%0Ahooks/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 moz-do-not-send="true"
href="https://github.com/CanonicalLtd/ubuntu-core-docs/blob/master/en/ref%0Aerence/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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:Snapcraft@lists.snapcraft.io">Snapcraft@lists.snapcraft.io</a><br>
Modify settings or unsubscribe at: <a
moz-do-not-send="true"
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 moz-do-not-send="true" href="http://niemeyer.net"
target="_blank">http://niemeyer.net</a></div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
<p><br>
</p>
</body>
</html>