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. -- Kyle Fazzari (kyrofa) Software Engineer Canonical Ltd. k...@canonical.com
signature.asc
Description: OpenPGP digital signature
-- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
