are the fetch-related variables in bitbake's bitbake.conf of any value?

are the fetch-related variables in bitbake's bitbake.conf of any value?

[Robert P. J. Day]

  more specific question related to my earlier post -- is there any
value whatever in the variables in bitbake's bitbake.conf file of the
form:

  FETCHCOMMAND*
  RESUMECOMMAND*
  UPDATECOMMAND*
  MKTEMP*CMD

nothing seems to use any of those. can they all just be deleted?
certainly, the FETCHCOMMAND* variables have been superseded by the
FETCHCMD* variables, no? i don't know about the remainder of them.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: are the fetch-related variables in bitbake's bitbake.conf of any value?

[Christopher Larson]

[-- Attachment #1: Type: text/plain, Size: 816 bytes --]

On Fri, Jun 20, 2014 at 9:00 AM, Robert P. J. Day <rpjday@crashcourse.ca>
wrote:

>
>   more specific question related to my earlier post -- is there any
> value whatever in the variables in bitbake's bitbake.conf file of the
> form:
>
>   FETCHCOMMAND*
>   RESUMECOMMAND*
>   UPDATECOMMAND*
>   MKTEMP*CMD
>
> nothing seems to use any of those. can they all just be deleted?
> certainly, the FETCHCOMMAND* variables have been superseded by the
> FETCHCMD* variables, no? i don't know about the remainder of them.


As far as I know, as you say, those were deprecated in favor of the
FETCHCMD vars, so can almost certainly be dropped.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

[-- Attachment #2: Type: text/html, Size: 1216 bytes --]

Re: are the fetch-related variables in bitbake's bitbake.conf of any value?

[Robert P. J. Day]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2114 bytes --]

On Fri, 20 Jun 2014, Christopher Larson wrote:

>
> On Fri, Jun 20, 2014 at 9:00 AM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>
>   more specific question related to my earlier post -- is there any
> value whatever in the variables in bitbake's bitbake.conf file of the
> form:
>
>   FETCHCOMMAND*
>   RESUMECOMMAND*
>   UPDATECOMMAND*
>   MKTEMP*CMD
>
> nothing seems to use any of those. can they all just be deleted?
> certainly, the FETCHCOMMAND* variables have been superseded by the
> FETCHCMD* variables, no? i don't know about the remainder of them.
>
> As far as I know, as you say, those were deprecated in favor of the
> FETCHCMD vars, so can almost certainly be dropped.

  one more question before i submit a patch to do some cleaning.
AFAICT, the bitbake.conf settings for RESUMECOMMAND* and
UPDATECOMMAND* variables can be removed as well since nothing in
bitbake refers to those variables, and it seems logical that bitbake
should not be setting variables that it doesn't directly use in some
way.

  however, i'm puzzled by this from the bitbake codebase:

$ grep -r "MKTEMP.*CMD" *
conf/bitbake.conf:MKTEMPCMD = "mktemp -q ${TMPBASE}"
conf/bitbake.conf:MKTEMPDIRCMD = "mktemp -d -q ${TMPBASE}"
lib/toaster/orm/fixtures/orm_views_testdata.json:        "variable_name": "MKTEMPCMD"
lib/toaster/orm/fixtures/orm_views_testdata.json:        "variable_name": "MKTEMPDIRCMD"
$

  so the only reference to the MKTEMP-related variables are in the
toaster directory in some .json files. what does that mean? if one
wanted to remove the MKTEMP* variables, would one also have to adjust
those .json files accordingly?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: are the fetch-related variables in bitbake's bitbake.conf of any value?

[Paul Eggleton]

On Friday 20 June 2014 12:23:12 Robert P. J. Day wrote:
> On Fri, 20 Jun 2014, Christopher Larson wrote:
> > On Fri, Jun 20, 2014 at 9:00 AM, Robert P. J. Day <rpjday@crashcourse.ca>
> > wrote:
> > 
> >   more specific question related to my earlier post -- is there any
> > value whatever in the variables in bitbake's bitbake.conf file of the
> > form:
> > 
> >   FETCHCOMMAND*
> >   RESUMECOMMAND*
> >   UPDATECOMMAND*
> >   MKTEMP*CMD
> > 
> > nothing seems to use any of those. can they all just be deleted?
> > certainly, the FETCHCOMMAND* variables have been superseded by the
> > FETCHCMD* variables, no? i don't know about the remainder of them.
> > 
> > As far as I know, as you say, those were deprecated in favor of the
> > FETCHCMD vars, so can almost certainly be dropped.
> 
>   one more question before i submit a patch to do some cleaning.
> AFAICT, the bitbake.conf settings for RESUMECOMMAND* and
> UPDATECOMMAND* variables can be removed as well since nothing in
> bitbake refers to those variables, and it seems logical that bitbake
> should not be setting variables that it doesn't directly use in some
> way.

Those look old to me as well.

>   however, i'm puzzled by this from the bitbake codebase:
> 
> $ grep -r "MKTEMP.*CMD" *
> conf/bitbake.conf:MKTEMPCMD = "mktemp -q ${TMPBASE}"
> conf/bitbake.conf:MKTEMPDIRCMD = "mktemp -d -q ${TMPBASE}"
> lib/toaster/orm/fixtures/orm_views_testdata.json:        "variable_name":
> "MKTEMPCMD" lib/toaster/orm/fixtures/orm_views_testdata.json:       
> "variable_name": "MKTEMPDIRCMD" $
> 
>   so the only reference to the MKTEMP-related variables are in the
> toaster directory in some .json files. what does that mean? if one
> wanted to remove the MKTEMP* variables, would one also have to adjust
> those .json files accordingly?

The intention is to provide a way for QA verify that Toaster is collecting the 
variable data correctly, but because the json files contain every variable 
value, they are already out-of-date. We probably ought to filter the list that 
is used for that test to make it more maintainable.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: are the fetch-related variables in bitbake's bitbake.conf of any value?

[Robert P. J. Day]

On Wed, 25 Jun 2014, Paul Eggleton wrote:

> On Friday 20 June 2014 12:23:12 Robert P. J. Day wrote:
> > On Fri, 20 Jun 2014, Christopher Larson wrote:
> > > On Fri, Jun 20, 2014 at 9:00 AM, Robert P. J. Day <rpjday@crashcourse.ca>
> > > wrote:
> > >
> > >   more specific question related to my earlier post -- is there any
> > > value whatever in the variables in bitbake's bitbake.conf file of the
> > > form:
> > >
> > >   FETCHCOMMAND*
> > >   RESUMECOMMAND*
> > >   UPDATECOMMAND*
> > >   MKTEMP*CMD
> > >
> > > nothing seems to use any of those. can they all just be deleted?
> > > certainly, the FETCHCOMMAND* variables have been superseded by the
> > > FETCHCMD* variables, no? i don't know about the remainder of them.
> > >
> > > As far as I know, as you say, those were deprecated in favor of the
> > > FETCHCMD vars, so can almost certainly be dropped.
> >
> >   one more question before i submit a patch to do some cleaning.
> > AFAICT, the bitbake.conf settings for RESUMECOMMAND* and
> > UPDATECOMMAND* variables can be removed as well since nothing in
> > bitbake refers to those variables, and it seems logical that bitbake
> > should not be setting variables that it doesn't directly use in some
> > way.
>
> Those look old to me as well.
>
> >   however, i'm puzzled by this from the bitbake codebase:
> >
> > $ grep -r "MKTEMP.*CMD" *
> > conf/bitbake.conf:MKTEMPCMD = "mktemp -q ${TMPBASE}"
> > conf/bitbake.conf:MKTEMPDIRCMD = "mktemp -d -q ${TMPBASE}"
> > lib/toaster/orm/fixtures/orm_views_testdata.json:        "variable_name":
> > "MKTEMPCMD" lib/toaster/orm/fixtures/orm_views_testdata.json:
> > "variable_name": "MKTEMPDIRCMD" $
> >
> >   so the only reference to the MKTEMP-related variables are in the
> > toaster directory in some .json files. what does that mean? if one
> > wanted to remove the MKTEMP* variables, would one also have to
> > adjust those .json files accordingly?
>
> The intention is to provide a way for QA verify that Toaster is
> collecting the variable data correctly, but because the json files
> contain every variable value, they are already out-of-date. We
> probably ought to filter the list that is used for that test to make
> it more maintainable.

  so, in short, it should be safe to ditch the
{FETCH,RESUME,UPDATE}COMMAND variable settings, but i'm still unclear
on what would need to be done re: the MKTEMP* variables -- i'll just
submit a patch taking out the first set, and let someone else worry
about the ones that show up in json files.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: are the fetch-related variables in bitbake's bitbake.conf of any value?

[Paul Eggleton]

On Wednesday 25 June 2014 11:03:44 Robert P. J. Day wrote:
> On Wed, 25 Jun 2014, Paul Eggleton wrote:
> > On Friday 20 June 2014 12:23:12 Robert P. J. Day wrote:
> > > On Fri, 20 Jun 2014, Christopher Larson wrote:
> > > > On Fri, Jun 20, 2014 at 9:00 AM, Robert P. J. Day
> > > > <rpjday@crashcourse.ca>
> > > > 
> > > > wrote:
> > > >   more specific question related to my earlier post -- is there any
> > > > 
> > > > value whatever in the variables in bitbake's bitbake.conf file of the
> > > > 
> > > > form:
> > > >   FETCHCOMMAND*
> > > >   RESUMECOMMAND*
> > > >   UPDATECOMMAND*
> > > >   MKTEMP*CMD
> > > > 
> > > > nothing seems to use any of those. can they all just be deleted?
> > > > certainly, the FETCHCOMMAND* variables have been superseded by the
> > > > FETCHCMD* variables, no? i don't know about the remainder of them.
> > > > 
> > > > As far as I know, as you say, those were deprecated in favor of the
> > > > FETCHCMD vars, so can almost certainly be dropped.
> > > > 
> > >   one more question before i submit a patch to do some cleaning.
> > > 
> > > AFAICT, the bitbake.conf settings for RESUMECOMMAND* and
> > > UPDATECOMMAND* variables can be removed as well since nothing in
> > > bitbake refers to those variables, and it seems logical that bitbake
> > > should not be setting variables that it doesn't directly use in some
> > > way.
> > 
> > Those look old to me as well.
> > 
> > >   however, i'm puzzled by this from the bitbake codebase:
> > > $ grep -r "MKTEMP.*CMD" *
> > > conf/bitbake.conf:MKTEMPCMD = "mktemp -q ${TMPBASE}"
> > > conf/bitbake.conf:MKTEMPDIRCMD = "mktemp -d -q ${TMPBASE}"
> > > lib/toaster/orm/fixtures/orm_views_testdata.json:       
> > > "variable_name":
> > > "MKTEMPCMD" lib/toaster/orm/fixtures/orm_views_testdata.json:
> > > "variable_name": "MKTEMPDIRCMD" $
> > > 
> > >   so the only reference to the MKTEMP-related variables are in the
> > > 
> > > toaster directory in some .json files. what does that mean? if one
> > > wanted to remove the MKTEMP* variables, would one also have to
> > > adjust those .json files accordingly?
> > 
> > The intention is to provide a way for QA verify that Toaster is
> > collecting the variable data correctly, but because the json files
> > contain every variable value, they are already out-of-date. We
> > probably ought to filter the list that is used for that test to make
> > it more maintainable.
> 
>   so, in short, it should be safe to ditch the
> {FETCH,RESUME,UPDATE}COMMAND variable settings, but i'm still unclear
> on what would need to be done re: the MKTEMP* variables -- i'll just
> submit a patch taking out the first set, and let someone else worry
> about the ones that show up in json files.

That sounds good to me.

Thanks,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre