You can try that, but it won’t work for build-packages. It might work for stage-packages because they’re pulled differently. The problem with build-packages is that they are pulled upfront by snapcraft before the prepare script is ran, so you can’t reference packages that are in your PPA/alternative repo. I have managed to fudge this by running apt install in addition to the add-apt-repository but it means we’re not being declarative anymore.
using the prepare step to call add-apt-repository will not by itself affect the snap filesystem. It will add the repository configuration into the build system’s /etc/apt/repos.list.d, which might mean it adds the repo into your host if you aren’t using a container to build. The repos added via prepare do not get used to provide build-packages because those are pulled up-front before the prepare script(s) are run, so you need to install any build requirements which are in an added repo separately in the prepare script.
I had a similar issue. I found out that the catkin plugin is using the PLUGIN_STAGE_SOURCES property. The stage phase will then use the sources provided by this property instead of the sources from the system.
What I did for the moment, until I find a better solution, is to fork the catkin.py plugin (I put it inside snap/plugins/custom_catkin.py).
Then add my custom repository around line 255:
Then change “plugin: catkin” in snapcraft.yaml by “plugin: custom-catkin”.
Btw, I add the key of the repo with a “nil” plugin and a prepare script.
Actually i am bit confuse to add WLAN Firmware in kernel snap, which will drastically increase the kernel image size.
What if i include the same in initramfs?
It will save some time to rebuild the kernel snap if there were some changes in WLAN Firmware or if i say there were some additional firmware which is underdevelopment for customize SBC based on Qualcom SOC .
And i will guide my kernel about initramfs through bootarg.
Someone please correct my understanding here.
I appreciate any help
since the initramfs is shipped inside the kernel snap i doubt you would gain any size benefit here … beyond this, the wlan module would not find its firmware on the rootfs running system in case something unloads/reloads the module.
the firmware is alredy in a separate snapcraft part in your yaml above, if you have the tree from the last build around only cleaning the firmware part and having snapcraft rebuild just that part will give you exactly that … just make sure there is no after: statement in your yaml that adds an interdependency between the parts.