* [PATCH 0/1] base-files: do_install.sigdata: remove the depends on DATE
@ 2014-03-25 3:10 Robert Yang
2014-03-25 3:10 ` [PATCH 1/1] " Robert Yang
0 siblings, 1 reply; 8+ messages in thread
From: Robert Yang @ 2014-03-25 3:10 UTC (permalink / raw)
To: openembedded-core
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(+)
--
1.8.3.1
^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH 1/1] base-files: do_install.sigdata: remove the depends on DATE
2014-03-25 3:10 [PATCH 0/1] base-files: do_install.sigdata: remove the depends on DATE Robert Yang
@ 2014-03-25 3:10 ` Robert Yang
2014-03-27 17:21 ` Chris Larson
0 siblings, 1 reply; 8+ messages in thread
From: Robert Yang @ 2014-03-25 3:10 UTC (permalink / raw)
To: openembedded-core
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 <liezhi.yang@windriver.com>
---
meta/recipes-core/base-files/base-files_3.0.14.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-core/base-files/base-files_3.0.14.bb b/meta/recipes-core/base-files/base-files_3.0.14.bb
index cee19a1..9699e31 100644
--- a/meta/recipes-core/base-files/base-files_3.0.14.bb
+++ b/meta/recipes-core/base-files/base-files_3.0.14.bb
@@ -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
--
1.8.3.1
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH 1/1] base-files: do_install.sigdata: remove the depends on DATE
2014-03-25 3:10 ` [PATCH 1/1] " Robert Yang
@ 2014-03-27 17:21 ` Chris Larson
2014-03-27 17:49 ` Richard Purdie
0 siblings, 1 reply; 8+ messages in thread
From: Chris Larson @ 2014-03-27 17:21 UTC (permalink / raw)
To: Robert Yang; +Cc: Patches and discussions about the oe-core layer
[-- Attachment #1: Type: text/plain, Size: 1116 bytes --]
On Mon, Mar 24, 2014 at 8:10 PM, Robert Yang <liezhi.yang@windriver.com>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]
>
> Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
>
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?
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
[-- Attachment #2: Type: text/html, Size: 1742 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/1] base-files: do_install.sigdata: remove the depends on DATE
2014-03-27 17:21 ` Chris Larson
@ 2014-03-27 17:49 ` Richard Purdie
2014-03-27 17:53 ` Chris Larson
0 siblings, 1 reply; 8+ messages in thread
From: Richard Purdie @ 2014-03-27 17:49 UTC (permalink / raw)
To: Chris Larson; +Cc: Patches and discussions about the oe-core layer
On Thu, 2014-03-27 at 10:21 -0700, Chris Larson wrote:
>
> On Mon, Mar 24, 2014 at 8:10 PM, Robert Yang
> <liezhi.yang@windriver.com> 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]
>
> Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
>
> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/1] base-files: do_install.sigdata: remove the depends on DATE
2014-03-27 17:49 ` Richard Purdie
@ 2014-03-27 17:53 ` Chris Larson
2014-03-27 18:13 ` Martin Jansa
0 siblings, 1 reply; 8+ messages in thread
From: Chris Larson @ 2014-03-27 17:53 UTC (permalink / raw)
To: Richard Purdie; +Cc: Patches and discussions about the oe-core layer
[-- Attachment #1: Type: text/plain, Size: 2000 bytes --]
On Thu, Mar 27, 2014 at 10:49 AM, Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:
> On Thu, 2014-03-27 at 10:21 -0700, Chris Larson wrote:
> >
> > On Mon, Mar 24, 2014 at 8:10 PM, Robert Yang
> > <liezhi.yang@windriver.com> 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]
> >
> > Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
> >
> > 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...
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*
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
[-- Attachment #2: Type: text/html, Size: 2817 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/1] base-files: do_install.sigdata: remove the depends on DATE
2014-03-27 17:53 ` Chris Larson
@ 2014-03-27 18:13 ` Martin Jansa
2014-03-27 18:31 ` Mark Hatle
0 siblings, 1 reply; 8+ messages in thread
From: Martin Jansa @ 2014-03-27 18:13 UTC (permalink / raw)
To: Chris Larson; +Cc: Patches and discussions about the oe-core layer
[-- Attachment #1: Type: text/plain, Size: 2625 bytes --]
On Thu, Mar 27, 2014 at 10:53:20AM -0700, Chris Larson wrote:
> On Thu, Mar 27, 2014 at 10:49 AM, Richard Purdie <
> richard.purdie@linuxfoundation.org> wrote:
>
> > On Thu, 2014-03-27 at 10:21 -0700, Chris Larson wrote:
> > >
> > > On Mon, Mar 24, 2014 at 8:10 PM, Robert Yang
> > > <liezhi.yang@windriver.com> 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]
> > >
> > > Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
> > >
> > > 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...
>
>
> 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).
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/1] base-files: do_install.sigdata: remove the depends on DATE
2014-03-27 18:13 ` Martin Jansa
@ 2014-03-27 18:31 ` Mark Hatle
2014-03-28 1:44 ` Robert Yang
0 siblings, 1 reply; 8+ messages in thread
From: Mark Hatle @ 2014-03-27 18:31 UTC (permalink / raw)
To: openembedded-core
On 3/27/14, 1:13 PM, Martin Jansa wrote:
> On Thu, Mar 27, 2014 at 10:53:20AM -0700, Chris Larson wrote:
>> On Thu, Mar 27, 2014 at 10:49 AM, Richard Purdie <
>> richard.purdie@linuxfoundation.org> wrote:
>>
>>> On Thu, 2014-03-27 at 10:21 -0700, Chris Larson wrote:
>>>>
>>>> On Mon, Mar 24, 2014 at 8:10 PM, Robert Yang
>>>> <liezhi.yang@windriver.com> 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]
>>>>
>>>> Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
>>>>
>>>> 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...
>>
>>
>> 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).
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/1] base-files: do_install.sigdata: remove the depends on DATE
2014-03-27 18:31 ` Mark Hatle
@ 2014-03-28 1:44 ` Robert Yang
0 siblings, 0 replies; 8+ messages in thread
From: Robert Yang @ 2014-03-28 1:44 UTC (permalink / raw)
To: Mark Hatle, Chris Larson, Martin Jansa, Purdie, Richard; +Cc: openembedded-core
On 03/28/2014 02:31 AM, Mark Hatle wrote:
> On 3/27/14, 1:13 PM, Martin Jansa wrote:
>> On Thu, Mar 27, 2014 at 10:53:20AM -0700, Chris Larson wrote:
>>> On Thu, Mar 27, 2014 at 10:49 AM, Richard Purdie <
>>> richard.purdie@linuxfoundation.org> wrote:
>>>
>>>> On Thu, 2014-03-27 at 10:21 -0700, Chris Larson wrote:
>>>>>
>>>>> On Mon, Mar 24, 2014 at 8:10 PM, Robert Yang
>>>>> <liezhi.yang@windriver.com> 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]
>>>>>
>>>>> Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
>>>>>
>>>>> 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...
>>>
>>>
>>> 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).
>
> 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
> --Mark
>
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2014-03-28 1:44 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-03-25 3:10 [PATCH 0/1] base-files: do_install.sigdata: remove the depends on DATE Robert Yang
2014-03-25 3:10 ` [PATCH 1/1] " Robert Yang
2014-03-27 17:21 ` Chris Larson
2014-03-27 17:49 ` Richard Purdie
2014-03-27 17:53 ` Chris Larson
2014-03-27 18:13 ` Martin Jansa
2014-03-27 18:31 ` Mark Hatle
2014-03-28 1:44 ` Robert Yang
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.