Patchwork [1/1] base-files: do_install.sigdata: remove the depends on DATE

login
register
mail settings
Submitter Robert Yang
Date March 25, 2014, 3:10 a.m.
Message ID <5d70928a37ce6dbebf41d42ca1f09d99b272a728.1395717014.git.liezhi.yang@windriver.com>
Download mbox | patch
Permalink /patch/69129/
State New
Headers show

Comments

Robert Yang - March 25, 2014, 3:10 a.m.
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(+)
Chris Larson - March 27, 2014, 5:21 p.m.
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?
Richard Purdie - March 27, 2014, 5:49 p.m.
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
Chris Larson - March 27, 2014, 5:53 p.m.
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*
Martin Jansa - March 27, 2014, 6:13 p.m.
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).
Mark Hatle - March 27, 2014, 6:31 p.m.
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
Robert Yang - March 28, 2014, 1:44 a.m.
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
>

Patch

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