All of lore.kernel.org
 help / color / mirror / Atom feed
From: Koen Kooi <k.kooi@student.utwente.nl>
To: Using the OpenEmbedded metadata to build Distributions
	<openembedded-devel@openembedded.org>
Subject: Re: RFC: Inclusion of bootloader utilities in task-base
Date: Sun, 02 Dec 2007 09:19:15 +0100	[thread overview]
Message-ID: <47526A83.30109@student.utwente.nl> (raw)
In-Reply-To: <47520EA7.8030507@whitby.id.au>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rod Whitby schreef:
> Some MACHINE configurations have FEATURES defined for 'uboot' and
> 'redboot'.  It looks like these are intended to identify the bootloader
> used on that machine.
> 
> These turn on additions to RDEPENDS in task-base for some bootloader
> utilities.
> 
> RFC #1: Is putting bootloader utilities in task-base a good idea in the
> first place?  Surely it's something that you either need for first boot
> (in which case it should be in the more primitive task-boot list), or
> it's something you use rarely after first boot (in which case it
> shouldn't be  wasting precious flash space in a task-base list but
> should just be ipkg installed when needed).
> 
> RFC #2: Shouldn't these be RRECOMMENDS unless they are absolutely
> critical, so that you can ipkg remove them if you don't want them.

I'm not familiar with the finer points of bootloaders, so I'm not really
qualified to respond to this, but if the utils are _critical_, they
should be RDEPENDS in task-boot, not task base.

regards,

Koen


> RFC #3: I want to add an 'apex' FEATURE for the Apex bootloader, and
> have that enable the 'apex-env' utility.  Any objections?  It would be
> done in the way decided by RFC #2, and subject to an RFC #1 decision.
> 
> RFC #4: If a machine (like the ixp4xx) can use a number of different
> bootloaders (redboot and apex in the case of the NSLU2), should they all
> be listed as features in machine.conf?
> 
> -- Rod
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> 


- --
koen@dominion.kabel.utwente.nl will go go away in december 2007, please
use k.kooi@student.utwente.nl instead.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFHUmqDMkyGM64RGpERApTWAJ0Tv04Q+IepkAvT3ciF0TZRMKaPQwCbB1r4
b/wlDDn2RfoPM/di65PDBFM=
=H8Wb
-----END PGP SIGNATURE-----



  reply	other threads:[~2007-12-02  8:22 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-02  1:47 RFC: Inclusion of bootloader utilities in task-base Rod Whitby
2007-12-02  8:19 ` Koen Kooi [this message]
2007-12-02 10:06   ` Rod Whitby
2007-12-02 19:27     ` Paul Sokolovsky
2007-12-02 21:25       ` Rod Whitby
2007-12-03 14:19         ` Paul Sokolovsky
2007-12-03 14:33           ` Rod Whitby

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=47526A83.30109@student.utwente.nl \
    --to=k.kooi@student.utwente.nl \
    --cc=openembedded-devel@lists.openembedded.org \
    --cc=openembedded-devel@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.