base-files: do_install.sigdata: remove the depends on DATE

PATCH In review Robert Yang 5 participants 8 messages Mar 25, 2014 – Mar 28, 2014

lore

Share & tools

lore

Robert Yang

author

2014-03-25 03:05 UTC #0 lore raw

cover base-files: do_install.sigdata: remove the depends on DATE

The following changes since commit 12217d8620e434a88433e7a60ff7fa8a1b51c6b1:

meta/conf/bitbake.conf: add STAMPCLEAN to BB_HASHBASE_WHITELIST (2014-03-25 10:14:26 +0800)

are available in the git repository at:

git://git.openembedded.org/openembedded-core-contrib rbt/basefiles
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/basefiles

Robert Yang (1):
base-files: do_install.sigdata: remove the depends on DATE

 meta/recipes-core/base-files/base-files_3.0.14.bb | 1 +
 1 file changed, 1 insertion(+)

Signature · 1 line

1.8.3.1

Robert Yang

author

2014-03-25 03:05 UTC #1 lore raw

PATCH 1/1 base-files: do_install.sigdata: remove the depends on DATE

If we run "bitbake -S base-files" today, and re-run it tomorrow with nothing changed, we would see that the do_install.sigdata changes because of:

do_intall -> do_install_basefilesissue -> DISTRO_VERSION -> DATE

We had set:
IMAGE_NAME[vardepsexclude] += "DATETIME"
in meta/conf/bitbake.conf, we can set a similar line in base-files_3.0.14.bb to fix the problem.

[YOCTO #6032]

Signed-off-by Robert Yang <[email protected]>

---
 meta/recipes-core/base-files/base-files_3.0.14.bb | 1 +
 1 file changed, 1 insertion(+)

meta/recipes-core/base-files/base-files_3.0.14.bb +1 -0

index cee19a1..9699e31 100644
@@ -103,6 +103,7 @@ do_install () {
 	ln -sf /proc/mounts ${D}${sysconfdir}/mtab
 }
 
+DISTRO_VERSION[vardepsexclude] += "DATE"
 do_install_basefilesissue () {
 	if [ "${hostname}" != "" ]; then
 		if [ -n "${MACHINE}" -a "${hostname}" = "openembedded" ]; then

Signature · 1 line

1.8.3.1

Chris Larson

2014-03-27 17:22 UTC #2 lore raw

Quoted 6 lines · Robert Yang

If we run "bitbake -S base-files" today, and re-run it tomorrow with nothing changed, we would see that the do_install.sigdata changes because of:
do_intall -> do_install_basefilesissue -> DISTRO_VERSION -> DATE

Quoted 9 lines

We had set:
IMAGE_NAME[vardepsexclude] += "DATETIME"
in meta/conf/bitbake.conf, we can set a similar line in base-files_3.0.14.bb to fix the problem.
[YOCTO #6032]
Signed-off-by Robert Yang <[email protected]>

Wont't this mean base-files wouldn't be rebuilt when the day changes? This seems problematic to me. I think this is a legitimate case for a checksum change. If the distro version changes due to the date changing, and the base-files includes the distro version in the issue file, then we'd *want* base-files to rebuild to ensure the issue file is correct, otherwise it'd be inaccurate, no?

Signature · 5 lines

Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

Richard Purdie

2014-03-27 17:49 UTC #3 lore raw

Quoted 19 lines · Chris Larson

On Mon, Mar 24, 2014 at 8:10 PM, Robert Yang <[email protected]> wrote:
If we run "bitbake -S base-files" today, and re-run it tomorrow with
nothing changed, we would see that the do_install.sigdata changes
because of:
do_intall -> do_install_basefilesissue -> DISTRO_VERSION -> DATE
We had set:
IMAGE_NAME[vardepsexclude] += "DATETIME"
in meta/conf/bitbake.conf, we can set a similar line in base-files_3.0.14.bb to fix the problem.
[YOCTO #6032]

Quoted 9 lines

Signed-off-by Robert Yang <[email protected]>
Wont't this mean base-files wouldn't be rebuilt when the day changes? This seems problematic to me. I think this is a legitimate case for a checksum change. If the distro version changes due to the date changing, and the base-files includes the distro version in the issue file, then we'd *want* base-files to rebuild to ensure the issue file is correct, otherwise it'd be inaccurate, no?

I'm torn on this. Package feed creators probably don't want a package feed where the package changes daily but I can see this from both sides, I have often wondered why my build was rebuilding base-files...

Cheers,

Richard

Chris Larson

2014-03-27 17:53 UTC #4 lore raw

Quoted 29 lines · Richard Purdie

Quoted 19 lines · Chris Larson
On Mon, Mar 24, 2014 at 8:10 PM, Robert Yang <[email protected]> wrote:
If we run "bitbake -S base-files" today, and re-run it tomorrow with
nothing changed, we would see that the do_install.sigdata changes
because of:
do_intall -> do_install_basefilesissue -> DISTRO_VERSION -> DATE
We had set:
IMAGE_NAME[vardepsexclude] += "DATETIME"
in meta/conf/bitbake.conf, we can set a similar line in base-files_3.0.14.bb to fix the problem.
[YOCTO #6032]
Quoted 9 lines
Signed-off-by Robert Yang <[email protected]>
Wont't this mean base-files wouldn't be rebuilt when the day changes? This seems problematic to me. I think this is a legitimate case for a checksum change. If the distro version changes due to the date changing, and the base-files includes the distro version in the issue file, then we'd *want* base-files to rebuild to ensure the issue file is correct, otherwise it'd be inaccurate, no?

Quoted 3 lines

I'm torn on this. Package feed creators probably don't want a package feed where the package changes daily but I can see this from both sides, I have often wondered why my build was rebuilding base-files...

Perhaps we should either not use DATE/TIME in the distro version at all, or have a variable which is the current date, and a variable which locks to the date of the creation of the TMPDIR but doesn't change after that, or something, as a more persistent build environment identifier to use for such cases. *shrug*

Signature · 5 lines

Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

Martin Jansa

2014-03-27 18:13 UTC #5 lore raw

Quoted 37 lines · Chris Larson

Quoted 29 lines · Richard Purdie
Quoted 19 lines · Chris Larson
On Mon, Mar 24, 2014 at 8:10 PM, Robert Yang <[email protected]> wrote:
If we run "bitbake -S base-files" today, and re-run it tomorrow with
nothing changed, we would see that the do_install.sigdata changes
because of:
do_intall -> do_install_basefilesissue -> DISTRO_VERSION -> DATE
We had set:
IMAGE_NAME[vardepsexclude] += "DATETIME"
in meta/conf/bitbake.conf, we can set a similar line in base-files_3.0.14.bb to fix the problem.
[YOCTO #6032]
Quoted 9 lines
Signed-off-by Robert Yang <[email protected]>
Wont't this mean base-files wouldn't be rebuilt when the day changes? This seems problematic to me. I think this is a legitimate case for a checksum change. If the distro version changes due to the date changing, and the base-files includes the distro version in the issue file, then we'd *want* base-files to rebuild to ensure the issue file is correct, otherwise it'd be inaccurate, no?
Quoted 3 lines
I'm torn on this. Package feed creators probably don't want a package feed where the package changes daily but I can see this from both sides, I have often wondered why my build was rebuilding base-files...

Quoted 5 lines

Perhaps we should either not use DATE/TIME in the distro version at all, or have a variable which is the current date, and a variable which locks to the date of the creation of the TMPDIR but doesn't change after that, or something, as a more persistent build environment identifier to use for such cases. *shrug*

I think that the DATE specific part should be moved to separate recipe which will clearly indicate it's just "build version".

I'm using shr-version recipe which just puts file in sysconfdir so it's not so surprising to see shr-version recipe being rebuilt everyday and I still know when the user last updated from feed.

It's also useful to pull such recipe into image by IMAGE_INSTALL not through packagegroup (as otherwise the packagegroup could be rebuilt every day as well - at least until runtime deps for packagegroups were excluded in signature handler).

Signature · 1 line

Martin 'JaMa' Jansa     jabber: [email protected]

Mark Hatle

2014-03-27 18:31 UTC #6 lore raw

Quoted 47 lines · Martin Jansa

Quoted 37 lines · Chris Larson
Quoted 29 lines · Richard Purdie
Quoted 19 lines · Chris Larson
On Mon, Mar 24, 2014 at 8:10 PM, Robert Yang <[email protected]> wrote:
If we run "bitbake -S base-files" today, and re-run it tomorrow with
nothing changed, we would see that the do_install.sigdata changes
because of:
do_intall -> do_install_basefilesissue -> DISTRO_VERSION -> DATE
We had set:
IMAGE_NAME[vardepsexclude] += "DATETIME"
in meta/conf/bitbake.conf, we can set a similar line in base-files_3.0.14.bb to fix the problem.
[YOCTO #6032]
Quoted 9 lines
Signed-off-by Robert Yang <[email protected]>
Wont't this mean base-files wouldn't be rebuilt when the day changes? This seems problematic to me. I think this is a legitimate case for a checksum change. If the distro version changes due to the date changing, and the base-files includes the distro version in the issue file, then we'd *want* base-files to rebuild to ensure the issue file is correct, otherwise it'd be inaccurate, no?
Quoted 3 lines
I'm torn on this. Package feed creators probably don't want a package feed where the package changes daily but I can see this from both sides, I have often wondered why my build was rebuilding base-files...
Quoted 5 lines
Perhaps we should either not use DATE/TIME in the distro version at all, or have a variable which is the current date, and a variable which locks to the date of the creation of the TMPDIR but doesn't change after that, or something, as a more persistent build environment identifier to use for such cases. *shrug*
I think that the DATE specific part should be moved to separate recipe which will clearly indicate it's just "build version".

Quoted 8 lines

I'm using shr-version recipe which just puts file in sysconfdir so it's not so surprising to see shr-version recipe being rebuilt everyday and I still know when the user last updated from feed.
It's also useful to pull such recipe into image by IMAGE_INSTALL not through packagegroup (as otherwise the packagegroup could be rebuilt every day as well - at least until runtime deps for packagegroups were excluded in signature handler).

This is a good place where separating version/build information from the basefiles makes a lot of sense. Rebuilding one small package daily for the purpose of knowing you are "current" is a lot better then potentially screwing with the base-files on the system (unless they've been changed and need to be updated.)

--Mark

Robert Yang

author

2014-03-28 01:44 UTC #7 lore raw

Quoted 57 lines · Mark Hatle

Quoted 47 lines · Martin Jansa
Quoted 37 lines · Chris Larson
Quoted 29 lines · Richard Purdie
Quoted 19 lines · Chris Larson
On Mon, Mar 24, 2014 at 8:10 PM, Robert Yang <[email protected]> wrote:
If we run "bitbake -S base-files" today, and re-run it tomorrow with
nothing changed, we would see that the do_install.sigdata changes
because of:
do_intall -> do_install_basefilesissue -> DISTRO_VERSION -> DATE
We had set:
IMAGE_NAME[vardepsexclude] += "DATETIME"
in meta/conf/bitbake.conf, we can set a similar line in base-files_3.0.14.bb to fix the problem.
[YOCTO #6032]
Quoted 9 lines
Signed-off-by Robert Yang <[email protected]>
Wont't this mean base-files wouldn't be rebuilt when the day changes? This seems problematic to me. I think this is a legitimate case for a checksum change. If the distro version changes due to the date changing, and the base-files includes the distro version in the issue file, then we'd *want* base-files to rebuild to ensure the issue file is correct, otherwise it'd be inaccurate, no?
Quoted 3 lines
I'm torn on this. Package feed creators probably don't want a package feed where the package changes daily but I can see this from both sides, I have often wondered why my build was rebuilding base-files...
Quoted 5 lines
Perhaps we should either not use DATE/TIME in the distro version at all, or have a variable which is the current date, and a variable which locks to the date of the creation of the TMPDIR but doesn't change after that, or something, as a more persistent build environment identifier to use for such cases. *shrug*
I think that the DATE specific part should be moved to separate recipe which will clearly indicate it's just "build version".
Quoted 8 lines
I'm using shr-version recipe which just puts file in sysconfdir so it's not so surprising to see shr-version recipe being rebuilt everyday and I still know when the user last updated from feed.
It's also useful to pull such recipe into image by IMAGE_INSTALL not through packagegroup (as otherwise the packagegroup could be rebuilt every day as well - at least until runtime deps for packagegroups were excluded in signature handler).

Quoted 6 lines

This is a good place where separating version/build information from the basefiles makes a lot of sense. Rebuilding one small package daily for the purpose of knowing you are "current" is a lot better then potentially screwing with the base-files on the system (unless they've been changed and need to be updated.)

After reading the threads, I think that we can file an enhancement bug for 1.7 to move the DATE/TIME related info to a separate recipe. For 1.6, I think that this patch is fine, the base-files get rebuild when DATE changes, but the image doesn't, and people may get confused since he can't reproduce this in a same day.

I'd like to file an enhancement bug for 1.7 and add you to CC list if you are fine.

// Robert

Quoted 2 lines

--Mark