All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Robert P. J. Day" <rpjday@crashcourse.ca>
To: OE Core mailing list <openembedded-core@lists.openembedded.org>
Subject: any *compelling* reasons to whitelist env vars for an OE build?
Date: Thu, 25 Mar 2021 10:08:19 -0400 (EDT)	[thread overview]
Message-ID: <429b51e-7cc5-54a7-a28-7e8beab0c77d@crashcourse.ca> (raw)


  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

             reply	other threads:[~2021-03-25 14:08 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-25 14:08 Robert P. J. Day [this message]
2021-03-25 14:15 ` [OE-core] any *compelling* reasons to whitelist env vars for an OE build? Mark Hatle
     [not found] ` <1b153bce-a66a-45ee-a5c6-963ea6fb1c82.949ef384-8293-46b8-903f-40a477c056ae.437c1374-0ed0-4179-b9f8-331319118723@emailsignatures365.codetwo.com>
     [not found]   ` <1b153bce-a66a-45ee-a5c6-963ea6fb1c82.0d2bd5fa-15cc-4b27-b94e-83614f9e5b38.1ce5b84f-c798-4314-b673-c5072a296141@emailsignatures365.codetwo.com>
2021-03-25 14:30     ` Mike Looijmans
2021-03-25 14:50       ` Robert P. J. Day
2021-03-25 16:02         ` Christopher Larson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=429b51e-7cc5-54a7-a28-7e8beab0c77d@crashcourse.ca \
    --to=rpjday@crashcourse.ca \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.