Skip to contentSkip to conversation

os-release: Exclude DATETIME from sstate signature

PATCH In review Richard Purdie 3 participants 3 messages Aug 25, 2015 – Aug 26, 2015

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 os-release: Exclude DATETIME from sstate signature

I'm torn over this, I can see someone wanting this to vary in each build. What pushed me to believe its incorrect in its current form is that it changes for every MACHINE build, making a complete mess if you try and generate package feeds using it.

The alternative would be to give up on allarch in this case and make it MACHINE specific which at least would then be more consistent when the package makes it to a package feed. If someone wants to do that, the can propose another patch but this change at least make package feed usage 'sane' again and avoids the perpetual rebuilds.

Incidentally, its worth noting that changes in source metadata revision used for the build and included in this recipe would still trigger rebuilds which is likely the common use case people actually care about.

meta/recipes-core/os-release/os-release.bb +1 -0
index 87fea6f..10a4570 100644
@@ -21,6 +21,7 @@ VERSION = "${DISTRO_VERSION}${@' (%s)' % DISTRO_CODENAME if 'DISTRO_CODENAME' in
 VERSION_ID = "${DISTRO_VERSION}"
 PRETTY_NAME = "${DISTRO_NAME} ${VERSION}"
 BUILD_ID ?= "${DATETIME}"
+BUILD_ID[vardepsexclude] = "DATETIME"
 
 python do_compile () {
     with open(d.expand('${B}/os-release'), 'w') as f:
#1 lore raw
Quoted 4 lines · Richard Purdie

I'm torn over this, I can see someone wanting this to vary in each build. What pushed me to believe its incorrect in its current form is that it changes for every MACHINE build, making a complete mess if you try and generate package feeds using it.

It's also worth pointing out that the BUILD_ID isn't included in the generated os-release file unless you add BUILD_ID to OS_RELEASE_FIELDS.

I'm personally not certain whether DATETIME makes sense as BUILD_ID a multi-MACHINE distro anyway.

Cheers,

Joshua

Quoted 26 lines

The alternative would be to give up on allarch in this case and make it MACHINE specific which at least would then be more consistent when the package makes it to a package feed. If someone wants to do that, the can propose another patch but this change at least make package feed usage 'sane' again and avoids the perpetual rebuilds.

Incidentally, its worth noting that changes in source metadata revision used for the build and included in this recipe would still trigger rebuilds which is likely the common use case people actually care about.

meta/recipes-core/os-release/os-release.bb +1 -0
index 87fea6f..10a4570 100644
@@ -21,6 +21,7 @@ VERSION = "${DISTRO_VERSION}${@' (%s)' % DISTRO_CODENAME if 'DISTRO_CODENAME' in
  VERSION_ID = "${DISTRO_VERSION}"
  PRETTY_NAME = "${DISTRO_NAME} ${VERSION}"
  BUILD_ID ?= "${DATETIME}"
+BUILD_ID[vardepsexclude] = "DATETIME"
 
  python do_compile () {
      with open(d.expand('${B}/os-release'), 'w') as f:
#2 lore raw
Quoted 11 lines · On Wednesday 26 August 2015 09:41:17 Joshua Lock wrote:
Quoted 4 lines · Richard Purdie

I'm torn over this, I can see someone wanting this to vary in each build. What pushed me to believe its incorrect in its current form is that it changes for every MACHINE build, making a complete mess if you try and generate package feeds using it.

It's also worth pointing out that the BUILD_ID isn't included in the generated os-release file unless you add BUILD_ID to OS_RELEASE_FIELDS.

I'm personally not certain whether DATETIME makes sense as BUILD_ID a multi-MACHINE distro anyway.

Indeed, since you have to invoke bitbake multiple times, under those circumstances you probably ought to be pre-calculating the BUILD_ID and passing it into the build.

Cheers,
Paul

Signature · 2 lines
Paul Eggleton
Intel Open Source Technology Centre