On Tue, Jan 31, 2017 at 12:02 PM, Kyle Fazzari <kyle.fazz...@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.jyri...@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 - 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 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.. > > -- > Kyle Fazzari (kyrofa) > Software Engineer > Canonical Ltd. > k...@canonical.com > > > -- > Snapcraft mailing list > Snapcraft@lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > >
-- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
