Slot type "file" gets unexpectedly suffixed with ".img"

[mschwan-phytec]

Is there a specific reason why regular "file" slots have their filename get a .img appended? https://github.com/rauc/meta-rauc/blob/1242c33d18052abc691a66eafb1cdf06a713db7a/classes-recipe/bundle.bbclass#L269 This seems counter-intuitive to me, as I would expect for a slot with imgtype "file" to be left unmodified. This is the case for the imgtype "boot", but that does not fit e.g. file slots used for a user application. I could workaround this by specifying the rename slotflag, but this also looks weird:

RAUC_SLOT_appfs ?= "rauc-appfs-example"
RAUC_SLOT_appfs[type] ?= "file"
RAUC_SLOT_appfs[file] ?= "rauc-appfs-example.tar.gz"
# Current workaround with "rename" slotflag
#RAUC_SLOT_appfs[rename] ?= "rauc-appfs-example.tar.gz"

Without this workaround, my bundle has the following slot, which obviously fails to install:

  [appfs]
        Filename:  rauc-appfs-example.tar.gz.img
        Checksum:  d28d50cd859adc3e3ca14057f44e95549a4b9fa285cfaac0b431289e8f9c2a17
        Size:      220 bytes
        Hooks:

As a proper fix I would suggest simply assigning the imgsource to the resulting imgname:

-            imgname = "%s.%s" % (imgsource, "img")
+            imgname = imgsource

As an addition, I think we could add another imgtype called "image", which gets .img appended to the filename.

What do you think about this? I think we had a similar discussion about this elsewhere but couldn't find any issue describing the reasoning behind it.

[ejoerns]

Is there a specific reason why regular "file" slots have their filename get a .img appended?

Yes, since random files normally have a file ending that is not recognized as an image type, I found this the most convenient way. However, you are not the first one stumbling across this.

https://github.com/rauc/meta-rauc/blob/1242c33d18052abc691a66eafb1cdf06a713db7a/classes-recipe/bundle.bbclass#L269

This seems counter-intuitive to me, as I would expect for a slot with imgtype "file" to be left unmodified. This is the case for the imgtype "boot", but that does not fit e.g. file slots used for a user application.

Yes, the expectation for bootloader images was that they are more likely to be supported by RAUC (and being .img anyway).

I could workaround this by specifying the rename slotflag, but this also looks weird:

Yes, we have introduced the [rename] flag for this purpose.

RAUC_SLOT_appfs ?= "rauc-appfs-example"
RAUC_SLOT_appfs[type] ?= "file"
RAUC_SLOT_appfs[file] ?= "rauc-appfs-example.tar.gz"
# Current workaround with "rename" slotflag
#RAUC_SLOT_appfs[rename] ?= "rauc-appfs-example.tar.gz"

Without this workaround, my bundle has the following slot, which obviously fails to install:

  [appfs]
        Filename:  rauc-appfs-example.tar.gz.img
        Checksum:  d28d50cd859adc3e3ca14057f44e95549a4b9fa285cfaac0b431289e8f9c2a17
        Size:      220 bytes
        Hooks:

For partitions that only have the purpose of holding the unpacked application directory, Artifact Updates may be the better solution in the future.

As a proper fix I would suggest simply assigning the imgsource to the resulting imgname:

-            imgname = "%s.%s" % (imgsource, "img")
+            imgname = imgsource

As an addition, I think we could add another imgtype called "image", which gets .img appended to the filename.

The image type already exists. Maybe it lacks some documentation. However, it expects to be generated from an 'image' (i.e. rootfs) recipe in Yocto.

Out of curiosity, how do you generate the application archive? Or is it just an integrated artifact deployed by a single recipe?

What do you think about this? I think we had a similar discussion about this elsewhere but couldn't find any issue describing the reasoning behind it.

[mschwan-phytec]

Is there a specific reason why regular "file" slots have their filename get a .img appended?

Yes, since random files normally have a file ending that is not recognized as an image type, I found this the most convenient way. However, you are not the first one stumbling across this.

But this only applies to binaries. Text-based files e.g. may have various endings, which with .img would falsely treat them as binary files. Maybe we can improve on this by not modifying the filename with imgtype file and only do this for a new imgtype meant for binaries, as proposed earlier.

As a proper fix I would suggest simply assigning the imgsource to the resulting imgname:

-            imgname = "%s.%s" % (imgsource, "img")
+            imgname = imgsource

As an addition, I think we could add another imgtype called "image", which gets .img appended to the filename.

The image type already exists. Maybe it lacks some documentation. However, it expects to be generated from an 'image' (i.e. rootfs) recipe in Yocto.

Ah yes, I meant binary or something similar. As explained above the approach you explained, only works for binary files, not text files nor archives.

Out of curiosity, how do you generate the application archive? Or is it just an integrated artifact deployed by a single recipe?

Yes, we currently do this via a single recipe generating an artifact that gets deployed to the DEPLOY_DIR in Yocto. AFAIK, there is currently no solution for multi-recipe artifacts, except the default image generation for root filesystems. Multiple recipes for one single artifact would at least require some new/custom bbclass.