<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 31, 2017 at 12:02 PM, Kyle Fazzari <span dir="ltr"><<a href="mailto:kyle.fazzari@canonical.com" target="_blank">kyle.fazzari@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
On 01/31/2017 08:40 AM, Didier Roche wrote:<br>
> Le 31/01/2017 à 17:18, Sergio Schvezov a écrit :<br>
>> On Tue, 31 Jan 2017 16:21:41 +0100, Olivier Tilloy wrote:<br>
>>> On Tue, Jan 31, 2017 at 2:12 PM, Timo Jyrinki<br>
>>> <<a href="mailto:timo.jyrinki@gmail.com">timo.jyrinki@gmail.com</a>> wrote:<br>
>>>>> Do we have a clear understanding of why this happens? Qt apps are<br>
>>>>> supposed to be binary compatible against newer releases.<br>
>>>>> One exception could be if the app itself is shipping some plugins,<br>
>>>>> because in that case I believe that these plugins are somehow bound to a<br>
>>>>> specific Qt version.<br>
>>>> Yes, it seems snaps like ubuntu-terminal-app and dekko ship their on<br>
>>>> Qt version which should not be the case when the platform snap is<br>
>>>> used.<br>
>>> This is a bit tricky: when packaging a Qt application that uses the<br>
>>> platform snap, snapcraft will use ldd to crawl the app’s binaries and<br>
>>> will automagically add the libraries that it depends on to the<br>
>>> resulting snap (those libs are taken from the host system).<br>
>> This will be disabled by default and snapcraft will error on missing libraries<br>
>> unless you tell it is ok.<br>
>><br>
> (first, sorry for the bad control+enter on my previous email)<br>
><br>
> I'm a little bit uncomfortable with that statement for mainly 2 reasons:<br>
> * Changing default behavior is always cumbersome to developers who just<br>
> wants to work on their app. Here, we are introducing a breaking change<br>
> (snaps that used to build won't build anymore, especially those on<br>
> core). It's annoying also for people who did hook up their CI to<br>
> autopublish a snap.<br>
><br>
> This is why we need to justify and carefully explain the change, in a<br>
> clear, defined way. I would suggest coordinating with David for a blog<br>
> post that we promote here and on the developer website:<br>
>   1. Why are we changing this? -> we are not doing this just to bother<br>
> you, developer, here is the technical reason why we are doing it.<br>
>   2. A small and minimal snippet of code of before/after so that people<br>
> aren't lost and know what to do<br>
>   3. When is it going to be released. Version, date, upgrade process.<br>
><br>
> As this default behavior changes a lot of things, we need to ensure as<br>
> well that all our code snippet and tutorials are updated. So<br>
> coordinating all the way, please!<br>
<br>
</div></div>I completely agree.<br>
<span class=""><br>
> * The second one is that it seems there is a disable mechanism, mainly<br>
> telling "I know what I'm doing". I think this isn't what we want to<br>
> achieve and it's not fine-grained enough.<br>
<br>
</span>Without knowing much about this change, I figure something like this<br>
would fit into build-attributes, which is per-part at least.<br>
<span class=""><br>
> A common use-case I can see is an app depending on a platform snap and<br>
> embedding additional libraries for some functionality. If we have to<br>
> disable the check for not erroring out on the platform snap libs, we may<br>
> miss, on snap creation, or upgrade or more… additional library checks.<br>
> It seems we shouldn't use a big hammer like this (if it's really what<br>
> I'm understanding from this statement), but rather trying to get a way<br>
> more fine-grained and precise approach.<br>
<br>
</span>You mean like asking the snap developer to provide an explicit list of<br>
libraries to error on? Or an explicit list of libraries to pull from the<br>
system if missing? Anything more fine-grained sounds messy to maintain<br>
from a snap developer perspective. And this applies to either direction:<br>
automatically pulling in dependencies from the system, or erroring on<br>
missing libraries.<br>
<br>
Note that, in your example, the consumer app should likely be built with<br>
the providing snap unpacked into the staging area. This guarantees that<br>
the consumer is build with the libraries etc. actually contained in the<br>
providing snap. Using this workflow, snapcraft doesn't do anything<br>
special with the libs contained in the staging area, even if they're<br>
filtered out of the final snap via the `prime` keyword. Where "anything<br>
special" is defined as trying to pull them in from the system, etc. I<br>
figure the "error on missing libs" would follow the same logic, and not<br>
error if the libs are satisfied in stage.<br></blockquote><div><br></div><div>From a developers perspective, it would be great if a workflow like the following could happen:</div><div> - if my snap uses other snaps via content-sharing, the providing snaps would be automatically unpacked during the build and used to satisfy depends so the libs are not copied into my snap</div><div>- if missing lib errors occur, give me the option to ignore and use system libs, or error-out with the list of missing deps</div><div><br></div><div>This would satisfy use cases where the providing snap contains all the libs my snap needs or just a portion of them. Sounds like we have most of this already in some form but not exactly..</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Kyle Fazzari (kyrofa)<br>
Software Engineer<br>
Canonical Ltd.<br>
<a href="mailto:kyle@canonical.com">kyle@canonical.com</a><br>
<br>
</font></span><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></div></div>