Changing default snapcraft behavior and erroring on missing libraries

[Didier Roche]

Le 31/01/2017 à 18:02, Kyle Fazzari a écrit :
>
> 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.

Thanks for the answer Kyle!
Indeed, if libs in stage are treated as you described (and the ldd isn't
done in prime/ thus), this would totally work, and avoid having this
manifest libs (that I didn't see each snaps having, but as a fallback,
only the platform snaps to generate it).

I guess it's just a matter of confirming the behavior will be this one
to iremove my second point of concern :)
Cheers,
Didier