any *compelling* reasons to whitelist env vars for an OE build?

any *compelling* reasons to whitelist env vars for an OE build?

[Robert P. J. Day]

  kind of a philosophical question, but i'm having a discussion with
some new colleagues about how to customize an OE (actually, wind river
linux) build, and these colleagues have, until now, used (whitelisted)
environment variables to pass info to the build, that info being used
to specify things like a development versus manufacturing build, and
so on.

  i suggested that i didn't think there was any really persuasive
reasons to use environment variables this way, as there are more than
enough configuration files to customize a build. i mentioned things
like:

  * machine config files
  * distro config files
  * defining packagegroup files
  * defining image files

and on and on and on.

  my point was that there are more than enough ways to support all the
customization you might need, that taking advantage of shell
environment variables strikes me as unnecessarily messy and, for that
matter, dangerous if you forget so set the environment.

  thoughts? am i out of line in advising them to use what OE offers
them, and not extract stuff from the environment?

rday

Re: [OE-core] any *compelling* reasons to whitelist env vars for an OE build?

[Mark Hatle]

On 3/25/21 9:08 AM, Robert P. J. Day wrote:
> 
>   kind of a philosophical question, but i'm having a discussion with
> some new colleagues about how to customize an OE (actually, wind river
> linux) build, and these colleagues have, until now, used (whitelisted)
> environment variables to pass info to the build, that info being used
> to specify things like a development versus manufacturing build, and
> so on.
> 
>   i suggested that i didn't think there was any really persuasive
> reasons to use environment variables this way, as there are more than
> enough configuration files to customize a build. i mentioned things
> like:
> 
>   * machine config files
>   * distro config files
>   * defining packagegroup files
>   * defining image files
> 
> and on and on and on.
> 
>   my point was that there are more than enough ways to support all the
> customization you might need, that taking advantage of shell
> environment variables strikes me as unnecessarily messy and, for that
> matter, dangerous if you forget so set the environment.
> 
>   thoughts? am i out of line in advising them to use what OE offers
> them, and not extract stuff from the environment?

I _always_ do builds like:

MACHINE=zynqmp-generic DISTRO=petalinux bitbake core-image-minimal

I don't want to have to update any configuration files to pass basic values into
the system.  This is also used heavily on my build systems so we can have a
common configuration for all builds, but built across a wide breadth of components.

I also occasionally use BB_ENV_EXTRAWHITE to add additional variables I might
want to override.  For instance, sometimes I want TMPDIR to go to a different
location, instead of having to modify local.conf (and then remember to put it
back the way it was) I can just add to the EXTRAWHITE, and call passing in TMPDIR.

--Mark

> rday
> 
> 
> 
> 
> 

Re: [OE-core] any *compelling* reasons to whitelist env vars for an OE build?

[Mike Looijmans]

I for one use a whitelist env vars daily, both hobby and work.

We tend to build for multiple machines, so in general we'd have something like 
this running on the build server:

for machine in mach1 mach2 mach3 mach4 ... mach40
do
    MACHINE=$machine bitbake image1 image2 image3
done

Being able to pass the MACHINE through the environment is a big win. We could 
alter a config file in the shell script, but that would change a file that 
we'd want under version control, and I really don't like it when builds change 
files under version control.

(The "40" machines is not exaggerated, I'm really involved in projects that 
build for that many targets)

Come to think of it, MACHINE is the one and only environment we ever pass to 
bitbake.

For release/test/production/debug/... etcetera I tend to use a different 
image, so you'd see:

MACHINE=mach1 bitbake interesting-image interesting-image-dev

So "interesting-image" would be the product, while the "dev" version would 
apply debug tweaks that make the rootfs writeable and enable the serial 
console for login and things like that.




Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijmans@topicproducts.com
W: www.topic.nl

Please consider the environment before printing this e-mail
On 25-03-2021 15:08, Robert P. J. Day via lists.openembedded.org wrote:
> 
>    kind of a philosophical question, but i'm having a discussion with
> some new colleagues about how to customize an OE (actually, wind river
> linux) build, and these colleagues have, until now, used (whitelisted)
> environment variables to pass info to the build, that info being used
> to specify things like a development versus manufacturing build, and
> so on.
> 
>    i suggested that i didn't think there was any really persuasive
> reasons to use environment variables this way, as there are more than
> enough configuration files to customize a build. i mentioned things
> like:
> 
>    * machine config files
>    * distro config files
>    * defining packagegroup files
>    * defining image files
> 
> and on and on and on.
> 
>    my point was that there are more than enough ways to support all the
> customization you might need, that taking advantage of shell
> environment variables strikes me as unnecessarily messy and, for that
> matter, dangerous if you forget so set the environment.
> 
>    thoughts? am i out of line in advising them to use what OE offers
> them, and not extract stuff from the environment?
> 
> rday
> 
> 
> 
> 
> 

Re: [OE-core] any *compelling* reasons to whitelist env vars for an OE build?

[Robert P. J. Day]

On Thu, 25 Mar 2021, Mike Looijmans wrote:

> I for one use a whitelist env vars daily, both hobby and work.
>
> We tend to build for multiple machines, so in general we'd have
> something like this running on the build server:
>
> for machine in mach1 mach2 mach3 mach4 ... mach40
> do
>    MACHINE=$machine bitbake image1 image2 image3
> done
>
> Being able to pass the MACHINE through the environment is a big win. We could
> alter a config file in the shell script, but that would change a file that
> we'd want under version control, and I really don't like it when builds change
> files under version control.
>
> (The "40" machines is not exaggerated, I'm really involved in projects that
> build for that many targets)
>
> Come to think of it, MACHINE is the one and only environment we ever pass to
> bitbake.
>
> For release/test/production/debug/... etcetera I tend to use a different
> image, so you'd see:
>
> MACHINE=mach1 bitbake interesting-image interesting-image-dev

  you and mark are right, i was being a bit too draconian -- being
able to select MACHINE and DISTRO on the bitbake invocation line are
obvious benefits.

  just to refresh my memory, what is it that identifies the env vars
that are by default passed through without any need for extra
whitelisting? is that BB_ENV_EXTRAWHITE? i recall that contains
MACHINE and DISTRO already, so that might be all i care about.

rday

Re: [OE-core] any *compelling* reasons to whitelist env vars for an OE build?

[Christopher Larson]

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

Just a quick note that you *can* script config file alterations without
having to alter files that may be under source control, that's what
auto.conf is for :)

On Thu, Mar 25, 2021 at 7:51 AM Robert P. J. Day <rpjday@crashcourse.ca>
wrote:

> On Thu, 25 Mar 2021, Mike Looijmans wrote:
>
> > I for one use a whitelist env vars daily, both hobby and work.
> >
> > We tend to build for multiple machines, so in general we'd have
> > something like this running on the build server:
> >
> > for machine in mach1 mach2 mach3 mach4 ... mach40
> > do
> >    MACHINE=$machine bitbake image1 image2 image3
> > done
> >
> > Being able to pass the MACHINE through the environment is a big win. We
> could
> > alter a config file in the shell script, but that would change a file
> that
> > we'd want under version control, and I really don't like it when builds
> change
> > files under version control.
> >
> > (The "40" machines is not exaggerated, I'm really involved in projects
> that
> > build for that many targets)
> >
> > Come to think of it, MACHINE is the one and only environment we ever
> pass to
> > bitbake.
> >
> > For release/test/production/debug/... etcetera I tend to use a different
> > image, so you'd see:
> >
> > MACHINE=mach1 bitbake interesting-image interesting-image-dev
>
>   you and mark are right, i was being a bit too draconian -- being
> able to select MACHINE and DISTRO on the bitbake invocation line are
> obvious benefits.
>
>   just to refresh my memory, what is it that identifies the env vars
> that are by default passed through without any need for extra
> whitelisting? is that BB_ENV_EXTRAWHITE? i recall that contains
> MACHINE and DISTRO already, so that might be all i care about.
>
> rday
>
> 
>
>

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

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