All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Eggleton <paul.eggleton@linux.intel.com>
To: "Robert P. J. Day" <rpjday@crashcourse.ca>
Cc: yocto@yoctoproject.org
Subject: Re: inconsistent pages out there for setting up your yocto dev host
Date: Fri, 23 Nov 2012 14:39:23 +0000	[thread overview]
Message-ID: <3038126.PEqOPPdATB@helios> (raw)
In-Reply-To: <alpine.DEB.2.02.1211230924450.3405@oneiric>

On Friday 23 November 2012 09:31:39 Robert P. J. Day wrote:
> On Thu, 22 Nov 2012, Paul Eggleton wrote:
> > On Thursday 22 November 2012 06:54:33 Robert P. J. Day wrote:
> > >   first, is ASSUME_PROVIDED technically completely superfluous?
> > > 
> > > it's clearly meant to speed up processing, but could one (if one
> > > wanted) unset it and have the processing still work (albeit more
> > > slowly, of course)?
> > 
> > If you like building things that you don't have to, sure, but I
> > wouldn't equate that to it being superfluous. Note that if you do
> > change this variable you are deviating from what has been tested, so
> > you do so at your own risk.
> 
>   wait, this point interests me so indulge me for a minute.
> obviously, there is a minimum collection of software one must install
> before starting to use OE/yocto -- at the very least, say, the
> fetching software -- so there will always be a page instructing a
> developer to install that minimum.
> 
>   afterwards, you can use ASSUME_PROVIDED to take advantage of that
> software, correct?  and that will certainly speed things up.  but in
> what way does that represent a "tested" configuration?

Well, we don't test with any other value of ASSUME_PROVIDED. If you add tools 
to ASSUME_PROVIDED that we would have otherwise built so that the host tools 
are used, we haven't tested the build with those host tools. Equally if you 
remove items from the default value of ASSUME_PROVIDED, we don't necessarily 
fully test the system with native tools that we don't normally build (although 
that's less likely to be an issue than the other case).

I'm not saying you can't change the value of ASSUME_PROVIDED - just that if 
you do and the build breaks, you get to keep both pieces :)

>   if you're on an allegedly supported distro, and you do an upgrade,
> it's entirely possible that one of those bits of software gets
> upgraded in a way that breaks OE/yocto, and by using ASSUME_PROVIDED,
> you'll automatically start using that newer utility.  or is the list
> of supported distros specifically only those installed out of the box
> and never updated?  if that's the case, then, yes, i agree with your
> position.

That's why we test specific versions of distributions, and with the Poky distro 
config we warn the user if the distro/distro version is untested. It's rare 
that you get that kind of breakage between major versions; if there were then 
other applications are likely to be affected so it would be considered a 
regression in that distro.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre


  reply	other threads:[~2012-11-23 14:39 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-21 22:23 inconsistent pages out there for setting up your yocto dev host Robert P. J. Day
2012-11-21 22:50 ` Paul Eggleton
2012-11-21 23:01   ` Rifenbark, Scott M
2012-11-21 23:45     ` Paul Eggleton
2012-11-22  1:19   ` Robert P. J. Day
2012-11-22  9:56     ` Paul Eggleton
2012-11-22 11:54       ` Robert P. J. Day
2012-11-22 15:35         ` Paul Eggleton
2012-11-23 14:31           ` Robert P. J. Day
2012-11-23 14:39             ` Paul Eggleton [this message]
2012-11-23 14:48               ` Robert P. J. Day
2012-11-24  8:03               ` Wolfgang Denk

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=3038126.PEqOPPdATB@helios \
    --to=paul.eggleton@linux.intel.com \
    --cc=rpjday@crashcourse.ca \
    --cc=yocto@yoctoproject.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.