<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Feb 22, 2015 at 4:58 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>
Am Freitag, den 20.02.2015, 15:21 -0500 schrieb Michael Terry:<br>
<span>> So I was thinking about the problem of snappifying a complex top-level<br>
> native program like unity8 (all the way down to Ubuntu Core, as one<br>
> giant snappy package).<br>
><br>
</span>your biggest blocker will currently be that you will need to hack<br>
hardware access into apparmor rules to get graphical bits to work at<br>
all ... (and these hacks will prevent you from landing it in the store<br>
so you will only be able to sideload your snap)<br>
<br>
the hardware access support in snaps is just being implemented and<br>
should be there soon though ...<br></blockquote><div><br></div><div>Ah interesting, good to know.<br></div><div><br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

also as mark mentioned, you will want to split up that work into<br>
framework and app layer (i would see shell, lightdm and indicators as<br>
the app layer here, everything below (Mir, Qt and platform-api) as<br>
framework)<br></blockquote><div><br></div><div>Yes.  That is certainly the long term goal.  But I was asked to specifically look into what would be required to do everything as one giant snap, as a shorter term goal.<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

while you can indeed do what you want and dump the whole stuff in a<br>
single unconfined snap, i doubt that would be maintainable and not much<br>
more than a finger training for a proper set-up later, not sure if you<br>
consider the amount of throw-away work this would cause worth the<br>
hassle ...<span></span></blockquote><div><br></div><div>Well I was hoping that some of the work would be useful even though some certainly would be throw-away in the long term.<br><br></div><div>Certainly, a reliable way to suck up a standard Debian package and its dependencies into a snap would be useful in a generic way. As would the ability to actually use that tree of files + the root tree of files.<br></div><div><br>But unsurprisingly, you folks have already thought about those problems!  Looks like the "incude-debs" yaml property handles the first problem and the "rootfs" property handles the second problem (so no need for LD_PRELOAD tricks like I talked about).<br><br></div><div>I gathered there is still some work to do on those properties?  Is that effort something that could use an extra hand, or is it already well along?<br></div><br></div>-- <br><div><div dir="ltr">-mt</div></div>
</div></div>