<div dir="ltr"><div>Hi Martin,</div><div><br></div><div class="gmail_extra"><div class="gmail_quote">On Tue, Nov 24, 2015 at 11:58 AM, Martin Pitt <span dir="ltr"><<a href="mailto:martin.pitt@ubuntu.com" target="_blank">martin.pitt@ubuntu.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I actually promised myself to not point this out for the umpteenth<br>
time, but it seems the conversation on the gdoc stopped.<br></blockquote><div><br></div><div>Sorry for making you come back onto this issue again. There might be information we're lacking, so your participation is appreciated here.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Michael Vogt [2015-11-23 17:48 +0100]:<br>
<span class="">> We implement the classic mode as a writable overlay.<br>
<br>
</span>I *strongly* recommend to not do this. We have dozens of bug reports<br>
of packages misbehaving on overlayfs; a particularly nasty case are<br>
packages that fail to upgrade/install on overlayfs, which is an use<br>
case which is relevant in the classic env (but not on a live system).<br></blockquote><div><br></div><div>Do we know which specific packages are broken and what causes these failures, so we can have a more clear idea of where the line between working and non-working is?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">It also degrades performance, causes stat() to misbehave (as the<br>
overlaying is leaked left and right into userspace, so e. g.<br>
"mountpoint" fails), and after a few rounds of dist-upgrades you still<br>
have the original old file system which is then just wasting disk<br>
space.<br></blockquote><div><br></div><div>In which way does stat misbehave, and do you have an idea of how the upstream feels about those issues so we can have a more informed view on the case?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
All this for saving a few seconds of time for the initial setup seems<br>
like an unacceptable trade-off to me..</blockquote><div><br></div><div>All of this to have a snap that works similar to every other snap, and takes no setup time the first time and every other time the snap is updated/reset.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">> It seems like we have the following options:<br>
><br>
> 1) Once ubuntu-classic is installed the snap can never be updated, but<br>
>    the *content* of the snap can be updated, i.e. you can keep your<br>
>    classic environment up-to-date via "sudo apt full-upgrade" (or we<br>
>    could even do it automatically via unattended-upgrades).<br>
<br>
</span>See above, dist-upgrading is not reliable, and it's rather fiddly to<br>
fix the chroot after such a failure happened; this rules out<br>
unattended-upgrades.<br></blockquote><div><br></div><div>It'd be nice to understand what is broken there.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
> 2) All system level changes (like additionally installed packages in<br>
>    ubuntu-classic) are lost on each snap update.<br>
<br>
</span>How would that be? As soon as you e. g. upgrade a deb, it's in the<br>
overlay, and if you change the same file in the underlay, that change<br></blockquote><div><br></div><div>Both Michael and myself have stated in this thread we're not changing the underlay and the overlay independently.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">> 3) All system level changes are not persistent and you get a fresh<br>
>    overlay each time snappy shell ubuntu-classic is run.<br>
<br>
</span>That's a practical option -- it avoids having to dist-upgrade manually<br></blockquote><div><br></div><div>That's not much different than option 2. The question is just when to reset.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">So this is essentially a question whether you want a schroot-like<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
experience or a real classic Ubuntu-like experience where you can<br>
install your favourite editor, debuggers, tools, etc. without having<br>
to reinstall and reconfigure it from scratch every time you use it.<br></blockquote><div><br></div><div>Well, it's really a blend of the two, but perhaps more like a schroot. You are playing in an environment inside another one, with consequences for how systemd, devices, etc, behave. At the same time, we do want people to install editors, debuggers, tools, etc, but people do that in schroots as well.</div><div><br></div><div><br></div></div><div class="gmail_signature">gustavo @ <a href="http://niemeyer.net" target="_blank">http://niemeyer.net</a></div>
</div></div>