Changing default snapcraft behavior and erroring on missing libraries

[Sergio Schvezov]

El miércoles, 1 de febrero de 2017 05h'40:03 ART, Didier Roche 
<didrocks at ubuntu.com> 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 
>>>>> <timo.jyrinki at gmail.com> 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