Are we still referring to overrides as “scriptlets”? I thought that terminology was being phased out.
I’m not sure, but the term isn’t terribly useful outside the context of the snippets themselves. It might make better sense to simply rename this 'Overriding build steps` (actually, as originally suggested by Sergio a couple of years ago). I’ll do that now.
I would shorten and just call them “overrides”.
Yep, good plan - I was mainly talking about changing the title for this page, but I’ll do both.
Should also mention core22 “craftctl default” variant.
Let’s say the default build/install process ends up installing files with absolute paths in them, which need to be fixed up to look inside the snap:
@kyrofa is it really necessary? I run my bash script with #!/bin/sh and it is able to find all its stage-packages without patched stuff. If system level /bin/sh is used to run the script, the system level sh should not be able to discover snap’s bin.
Totally depends on the snap and what absolute paths we’re talking about, here. This was just an example for where overriding might be useful, that’s all.
Can you provide a real world example where snap isolation breaks and patching these paths is necessary?
@degville – We should indeed mention that snapcraftctl <step> is now deprecated in favor of craftctl default with snapcraft 7.x and base: core22. I don’t remember when snapcraftctl will be officially removed, but I would guess with base: core24 and snapcraft 8.x…
@degville, could you please mention that, when using “source-type: local”, the snapcraft “pull” step creates hard links. Thus, the original local source is also being change if the developers patches the code base.
We would need to provide the above information as a warning.
Thanks Bugra