Changing default snapcraft behavior and erroring on missing libraries

[Sergio Schvezov]

On Tue, 31 Jan 2017 12:55:19 -0500, Bill Filler wrote:
> On Tue, Jan 31, 2017 at 12:02 PM, Kyle Fazzari <kyle.fazzari at canonical.com>
> wrote:
>
>>
>>
>> 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.
>>
>
> From a developers perspective, it would be great if a workflow like the
> following could happen:
>  - 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

This is why I told the SDK team to build a "release tarball" of whatever their framework is, with this people would just `after` it and it would just work. This will avoid the need for adding build packages equivalent to those of whatever that snap provides or for you guys to depend on a PPA to be able to build.

> - if missing lib errors occur, give me the option to ignore and use system
> libs, or error-out with the list of missing deps

This is planned.

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

Right. Also, this is just planned, but the details and execution haven't been finalized given that I haven't discussed with everyone.

-- 
Sent using Dekko from my Ubuntu device