El miércoles, 1 de febrero de 2017 05h'40:03 ART, Didier Roche
<[email protected]> escribió:
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
<[email protected]> wrote:
* 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 :)
https://github.com/snapcore/snapcraft/blob/master/integration_tests/test_library_precedence.py#L28
--
Enviado con Dekko desde mi dispositivo Ubuntu
--
Snapcraft mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/snapcraft
