| Summary: | Toolchain archive contains DISTRO_VERSION instead of SDK_VERSION | ||
|---|---|---|---|
| Product: | [Yocto Project Subprojects] ADT | Reporter: | Reinette Chatre <reinette.chatre> |
| Component: | adt | Assignee: | Jessica <jessica.zhang> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | Medium | CC: | alexandru.c.georgescu, jessica.zhang, poky.adt.watcher, poky.watcher |
| Version: | unspecified | ||
| Target Milestone: | 1.5 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | --- | |
|
Description
Reinette Chatre
2012-04-18 19:11:53 UTC
Hi Reinette, I think this is intended, since the DISTRO_VERSION provide us the timestamp info between releases. And for toolchain they're expected to be extracted to the fixed location which is SDK_VERSION that is the same as DISTRO_VERSION except the timestamp part. But for each official release, the DISTRON_VERSION and SDK_VERSION are the same. e.g. 1.2 (In reply to comment #1) > I think this is intended, since the DISTRO_VERSION provide us the timestamp > info between releases. And for toolchain they're expected to be extracted to > the fixed location which is SDK_VERSION that is the same as DISTRO_VERSION > except the timestamp part. But for each official release, the DISTRON_VERSION > and SDK_VERSION are the same. e.g. 1.2 This is very reasonable if image builds are restricted to what is provided in the poky repo. Things start to get confusing when the poky repo is used as a base by somebody who wants to build their own distro. Of course, when you build your own distro you set a new value for DISTRO and DISTRO_VERSION ... and immediately the assumptions from above break down since it is not given that the new DISTRO_VERSION will include a timestamp. You mention that "And for toolchain they're expected to be extracted to > the fixed location which is SDK_VERSION that is the same as DISTRO_VERSION > except the timestamp part." I mostly agree with this. I would really like if the toolchain is extracted at location that is same as DISTRO_VERSION, but I do think there should be any assumption of a timestamp. Having a value SDK_VERSION, yet using a different value (DISTRO_VERSION) in the file generated for the SDK is very confusing when building your own distro. I see your points and we'll see whether we can make some changes in 1.3. I've looked at the usage of SDK_VERSION it mainly for places that we only need DISTRO_VERSION without timestamp. So if you think the SDK_VERSION existence cause confusion, we can get rid off if and change to DISTRO_PREFIX. So we can continue use DISTRO_VERSION when generate toolchain tar ball and preserve the desired behavior. How do you think? (In reply to comment #4) > I've looked at the usage of SDK_VERSION it mainly for places that we only > need DISTRO_VERSION without timestamp. So if you think the SDK_VERSION > existence cause confusion, we can get rid off if and change to > DISTRO_PREFIX. So we can continue use DISTRO_VERSION when generate > toolchain tar ball and preserve the desired behavior. How do you think? Why not just use SDK_VERSION in TOOLCHAIN_OUTPUTNAME ? As the name implies it is the version of the SDK so it seems reasonable to expect that if any version number be included in the toolchain output then it will be SDK_VERSION. but the case is for between release built, we want to show the timestamp for things built out, that's why we are using DISTRO_VERSION, between releases it's current_release+snapshot_timpestamp, only for release build it'll be changed to release, which is much clearer from a sw develope and release process perspective. (In reply to comment #6) > but the case is for between release built, we want to show the timestamp for > things built out, that's why we are using DISTRO_VERSION, between releases > it's current_release+snapshot_timpestamp, only for release build it'll be > changed to release, which is much clearer from a sw develope and release > process perspective. Could you please elaborate why is a timestamp needed as part of filename between builds? OK, for example, between releases, our built out image will have name e.g. core-image-sato-qemux86-64-20120509051712.rootfs.ext3 and the corresponding toolchain name will be poky-eglibc-i686-x86_64-toolchain-gmae-1.2+snapshot-20120509.tar.bz2 , so it easy to tell the toolchain can be used against which image. If we just use SDK_VERSION, then the name will be poky-eglibc-i686-x86_64-toolchain-gmae-1.2+snapshot which is hard to map to the correct image. So the timestamp definitely helps in this case. (In reply to comment #8) > OK, for example, between releases, our built out image will have name e.g. > core-image-sato-qemux86-64-20120509051712.rootfs.ext3 and the corresponding > toolchain name will be > poky-eglibc-i686-x86_64-toolchain-gmae-1.2+snapshot-20120509.tar.bz2 , so it > easy to tell the toolchain can be used against which image. If we just use > SDK_VERSION, then the name will be > poky-eglibc-i686-x86_64-toolchain-gmae-1.2+snapshot which is hard to map to > the correct image. So the timestamp definitely helps in this case. That does not look easy to me :) I do not understand the prevalent usage of timestamps. Here is what I currently do to have things make sense to me: DISTRO_VERSION = "${@subprocess.check_output(["git", "describe"]).strip()}" IMAGE_NAME = "${IMAGE_BASENAME}-${MACHINE}-${DISTRO_VERSION}" SDK_VERSION = "${DISTRO_VERSION}" The above shows exactly the same version in image and toolchain output which makes it clear that they match. A toolchain is not always built around the same time as the image so using the timestamp as a way to match is fallable. The above may be more information than what you need though. The issue reported here is that DISTRO_VERSION is used to name the SDK output while there is a SDK_VERSION available. If your workflow prevents its change then so be it. I will not insist on its change since as you can see I do set them as the same value. Hi Reinette, With the sdk now is relocatable we should be able to make the changes that make the toolchain name using SDK_VERSION. I'll make the change for 1.5. Thanks, Jessica Verified. |