[oe] [Angstrom-devel] RFC: Add ipkg to minimal image

[Marcin Juszkiewicz]

Dnia niedziela, 2 grudnia 2007, Richard Purdie napisał:
> On Sun, 2007-12-02 at 09:17 +0100, Koen Kooi wrote:
> > Rod Whitby schreef:

> > > RFC #1:
> > >> Is there a reason why minimal-image does not include ipkg?  What
> > >> exactly is the definition of what should be in minimal-image which
> > >> excludes the ability to install further packages?
> >
> > Marcin and I had a discussion about that, but I can't remember the
> > outcome. So "I have no strong opinions on that".
>
> I think minimal was really intended for people trying to boot systems
> for the first time and really is 'the bare essentials to boot'. Having
> said that I appreciate the problem of creating an image cut down enough
> for the NSLU2.

minimal-image was meant as something really small which can be used to 
just boot device into something usable. For different machines 'usable' 
has different meaning and this should be covered by task-boot or 
MACHINE_ESSENTIAL_ variables. 

Zaurus palmtops are usable with just busybox + keymaps, for devboards it 
usually mean busybox (getty on serial port is automatically started), for 
nslu2 it means Ethernet + ssh/telnet daemon.

I see no problem with creating 'minimal-with-ipkg' image under better 
name. Let 'minimal-image' be really minimal - example usage is devboard 
with problems with NAND accessing and MMC card - all what is available is 
u-boot with ethernet so booting over tftp with kernel and initrd (or 
kernel with initramfs) makes it working.

> Ideally, MACHINE=nslu2 should make the console image become small
> enough to be usable for the device even if that different compared to
> the minimal image is just the package manager due to size
> constraints...

NSLU2 is example of device which can do really many things but rootfs 
space is limited. When it comes to Ångström defaults it means bt, wifi, 
usb host so 'task-base' starts to depend on too many stuff to be usable 
with internal flash. This device really needs special image for internal 
rootfs space.

> On a related but different note, the presence of a package manager or
> not sounds like an DISTRO_FEATURE. Perhaps we should add
> "package-manager" as a DISTRO_FEATURE and then use this to decide
> whether a package manager should be installed into an image. The
> package manager to install should determined by the class building the
> image so you end up with a package manager appropriate to the image -
> ipkg or dpkg+apt currently.

This sounds good - no use for package manager on systems which are 
upgraded only by reflashing (due to many reasons).

-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

           Q:      What's a light-year?
           A:      One-third less calories than a regular year.