Changing default snapcraft behavior and erroring on missing libraries

[Kyle Fazzari]

On 01/31/2017 08:40 AM, Didier Roche wrote:
> 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!

I completely agree.

> * 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.

Without knowing much about this change, I figure something like this
would fit into build-attributes, which is per-part at least.

> 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.

You mean like asking the snap developer to provide an explicit list of
libraries to error on? Or an explicit list of libraries to pull from the
system if missing? Anything more fine-grained sounds messy to maintain
from a snap developer perspective. And this applies to either direction:
automatically pulling in dependencies from the system, or erroring on
missing libraries.

Note that, in your example, the consumer app should likely be built with
the providing snap unpacked into the staging area. This guarantees that
the consumer is build with the libraries etc. actually contained in the
providing snap. Using this workflow, snapcraft doesn't do anything
special with the libs contained in the staging area, even if they're
filtered out of the final snap via the `prime` keyword. Where "anything
special" is defined as trying to pull them in from the system, etc. I
figure the "error on missing libs" would follow the same logic, and not
error if the libs are satisfied in stage.

-- 
Kyle Fazzari (kyrofa)
Software Engineer
Canonical Ltd.
kyle at canonical.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/snapcraft/attachments/20170131/aaaccf16/attachment.sig>