Changing default snapcraft behavior and erroring on missing libraries

[Didier Roche]

Le 31/01/2017 à 17:18, Sergio Schvezov a écrit :
> On Tue, 31 Jan 2017 16:21:41 +0100, Olivier Tilloy wrote:
>> On Tue, Jan 31, 2017 at 2:12 PM, Timo Jyrinki 
>> <timo.jyrinki at gmail.com> wrote:
>>>> Do we have a clear understanding of why this happens? Qt apps are
>>>> supposed to be binary compatible against newer releases.
>>>> One exception could be if the app itself is shipping some plugins,
>>>> because in that case I believe that these plugins are somehow bound to a
>>>> specific Qt version.
>>> Yes, it seems snaps like ubuntu-terminal-app and dekko ship their on
>>> Qt version which should not be the case when the platform snap is
>>> used.
>> This is a bit tricky: when packaging a Qt application that uses the
>> platform snap, snapcraft will use ldd to crawl the app’s binaries and
>> will automagically add the libraries that it depends on to the
>> resulting snap (those libs are taken from the host system).
> This will be disabled by default and snapcraft will error on missing libraries
> unless you tell it is ok.
>
(first, sorry for the bad control+enter on my previous email)

I'm a little bit uncomfortable with that statement for mainly 2 reasons:
* Changing default behavior is always cumbersome to developers who just
wants to work on their app. Here, we are introducing a breaking change
(snaps that used to build won't build anymore, especially those on
core). It's annoying also for people who did hook up their CI to
autopublish a snap.

This is why we need to justify and carefully explain the change, in a
clear, defined way. I would suggest coordinating with David for a blog
post that we promote here and on the developer website:
  1. Why are we changing this? -> we are not doing this just to bother
you, developer, here is the technical reason why we are doing it.
  2. A small and minimal snippet of code of before/after so that people
aren't lost and know what to do
  3. When is it going to be released. Version, date, upgrade process.

As this default behavior changes a lot of things, we need to ensure as
well that all our code snippet and tutorials are updated. So
coordinating all the way, please!

* The second one is that it seems there is a disable mechanism, mainly
telling "I know what I'm doing". I think this isn't what we want to
achieve and it's not fine-grained enough.

A common use-case I can see is an app depending on a platform snap and
embedding additional libraries for some functionality. If we have to
disable the check for not erroring out on the platform snap libs, we may
miss, on snap creation, or upgrade or more… additional library checks.
It seems we shouldn't use a big hammer like this (if it's really what
I'm understanding from this statement), but rather trying to get a way
more fine-grained and precise approach.

Thoughts?
Didier