On 29 March 2018 at 11:20, Mirza Krak <mi...@mkrak.org> wrote:
> Hi.
>
> I am working with a project that has a custom image type, "sdimg". The
> image works fine but it is when I try to apply CONVERSION_CMDs that I
> see some interesting things.
>
> The image output is:
>
> ${IMGDEPLOYDIR}/${IMAGE_NAME}.$suffix
>
> There is also a soft-link:
>
> ln -sfn "${IMAGE_NAME}.$suffix"
> "${DEPLOY_DIR_IMAGE}/${IMAGE_BASENAME}-${MACHINE}.$suffix"
>
> Now the interesting part comes when I try this:
>
> IMAGE_FSTYPES += "sdimg.gz"
>
> This results in a empty gz file, but I already know why and that is
> because the "normal" image does not contain IMAGE_NAME_SUFFIX in the
> output name, on which the CONVERSION_CMDs rely on [1].
>
> So instead of changing the image name I was hoping that this should
> work (default is ".rootfs" in image_types.bbclass):
>
> IMAGE_NAME_SUFFIX_sdimg = ""
>
> But above only partly works. It will generate a proper "gz" version of
> "sdimg" but it fails to create a soft-link, that is
> ${IMAGE_BASENAME}-${MACHINE}.sdimg.gz -> ${IMAGE_NAME}.sdimg.gz. And I
> have traced down on why. It is because image.bbclass still reads
> IMAGE_NAME_SUFFIX as ".rootfs" in create_symlinks[2] even though I
> have set it to something else for my specific image type (override).
>
> I have a couple of workarounds for this already but still wanted to
> report this and see what the community thinks about this. I would
> expect what I am trying to do, to work. That is to set
> IMAGE_NAME_SUFFIX to empty for the custom image.
>
> But you might be of another opinion.
>
> [1].
> https://github.com/openembedded/openembedded-core/blob/master/meta/classes/image_types.bbclass#L284
> [2].
> https://github.com/openembedded/openembedded-core/blob/master/meta/classes/image.bbclass#L592-L614
>
Re-send, because my initial mail got stuck for moderator approval due
to not being registered on the mailing-list with this email, I am now
and bypassing moderators :).
--
Med Vänliga Hälsningar / Best Regards
Mirza Krak
email: mi...@mkrak.org
web: http://mkrak.org
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
