Here I read some useful info on OSTree and I would like understanding how to use it in a “good” way for my Torizon OS custom build (based on Toradex “best practises”).
I read
Inside the OSTree repository, the builds are organized in branches (or REFs). REFs follow a naming convention consisting of the Torizon OS major version number, machine name, distribution name, image name and release type, e.g.:
And so I can imagine how to call my OSTree branches (I can take into accout easily change of Torizon OS major version, SoM, carrier board, image name, …).
When I use a tcb template in VS code to build my custom Torizon OS build, I see there is the parameter tcb.packageName in settings.json
How should I use this?
Should I take a “fixed” name? Or should it change based on Torizon OS major version, SoM, carrier board, image name, …
Is tcb.packageName the label that appears as the Package Name in torizon.io?
It seems to me that Package Name in torizon.io is quite similar to OSTree branch
Basically there is scarthgap instead of 4, but I understood that in Toradex terminology 4 is a tag that refers to Torizon OS 7 / scarthgap-based.
Or is this because the package name must “match” OSTree branch?
And so if I change OSTree branch (as an example, I upgrade to Torizon OS 7) I should change the tcb.packageName too?
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
Based on the context provided, when working with Torizon OS custom builds, it is recommended to align the tcb.packageName with the OSTree branch naming convention. This means that the tcb.packageName should reflect changes in the Torizon OS major version, SoM, carrier board, and image name. This alignment ensures consistency and clarity, making it easier to manage and identify your builds.
The tcb.packageName is indeed similar to the OSTree branch, and it should ideally match the OSTree branch. If you upgrade your OSTree branch, for example, to Torizon OS 7, you should also update the tcb.packageName to reflect this change. This helps maintain a clear relationship between the package and its corresponding OSTree branch.
In summary, you should not use a “fixed” name for tcb.packageName. Instead, it should dynamically change to match the OSTree branch, ensuring that your package name remains relevant and organized as you update your builds.
Please, also check if these links can help you solve your problem:
--package-name TARGET
Package name for docker-compose or generic package file (default: name of file being pushed to OTA)
or OSTree reference (default: same as REF).
First of all, to be clear the “package name” and the OSTree branch/reference name are two completely different things. The “package name” is what is seen in our web UI. It also used throughout the metadata involved with our update system.
The OSTree branch/reference name is just internal to the OSTree repository itself. Our update system does not even care what the OSTree branch/reference name is. In the case of our pre-uploaded packages we just happen to use the same string for both the package name and the OSTree branch/reference name.
Unless you are working with OSTree directly (which most people have no need to) you probably never need to worry about OSTree branch/reference name. If you’re just uploading OS packages to use with our Cloud update framework, then you only really need to concern yourself with the package name. You can use whatever naming schema you want that helps you keep your OS packages organized.
It should also be noted that OS packages have an associated hardware ID (i.e. verdin-imx8mp). This means these OS packages are already essentially hardware specific.
Not sure if that helps clarify anything or if you now have follow-up questions.
Only one thing:
using “Create from template” from the vscode-torizon extension to create a tcb project I can’t use / char in the name (that is the package name) because it’s impossible to have / char in a container/service name.
tcb project is different from a common container project like all the other ones.
Is it possible to remove this limitation (for tcb project only)?
They said for now you should be able to just create the project with whatever valid name. Then for the package-name just change it manually in your config settings for the project. That way you can have the / character for your package names.
