All of lore.kernel.org
 help / color / mirror / Atom feed
From: Koen Kooi <k.kooi@student.utwente.nl>
To: angstrom-distro-devel@linuxtogo.org
Cc: Using the OpenEmbedded metadata to build Distributions
	<openembedded-devel@openembedded.org>
Subject: Re: [Angstrom-devel] RFC: Add ipkg to minimal image
Date: Sun, 02 Dec 2007 16:35:33 +0100	[thread overview]
Message-ID: <4752D0C5.5080001@student.utwente.nl> (raw)
In-Reply-To: <4752B053.1040909@student.utwente.nl>

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

Koen Kooi schreef:
> Richard Purdie schreef:
>> On Sun, 2007-12-02 at 09:17 +0100, Koen Kooi wrote:
>>> Rod Whitby schreef:
>>>> Rod Whitby wrote:
>>>>> I just realised that minimal-image.bb doesn't include ipkg, whereas the
>>>>> first image which does include ipkg (console-image) includes a whole lot
>>>>> of other stuff which could be installed using ipkg after first boot and
>>>>> network access, and which make the image too big for a machine with
>>>>> limited flash space (like an NSLU2).
>>>> 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. 
> 
>> 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...
> 
>> 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.
> 
> For angstrom it's an IMAGE_FEATURE, since some images need it (e.g.
> console-image) and others don't (e.g. initramfs).
> Right not you can set ANGSTROM_PKG_FORMAT to 'deb' or 'ipkg' to create
> images using .ipk or .deb packages, with no rebuild needed, changing it
> halfway during a build and restarting bitbake "Just Works(TM)". Any
> changes to how a packagemanager is installed must keep that
> 'automagical' feature. The only thing missing in Rods patch is to set
> the packagemanager var in
> conf/distro/include/angstrom-package-{deb,ipkg}.inc.

To make it a bit more clear:

There are 3 seperate items being discusses here:

 1. how to stop a packagemanager getting into an image
 2. selecting which packageformat the build should use
 3. selecting which packagemanager handles which packageformat (ipkg can
handle .debs for example)

ANGSTROM_PKG_FORMAT handles 2. and 3., but not 1. (yet)

I think having a flag indicating *which* packagemanager gets is (like
Rods patch does) is a good thing, but a flag toggling the presence of
the packagemanager wouldn't be, since you can't distinguish the
resulting images from each other.
I think creating e.g. <foo>-nopm.bb recipes that do 'require <foo>.bb ;
PACKAGE_MANAGER = " "' would be the least confusing option.

I hope this clears things up a bit.

regards,

Koen



- --
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)

iD8DBQFHUtDFMkyGM64RGpERAq9xAJ9XRjlHv8LPiLcdnARLUUBXCc2t2ACfXM03
R/javXrBLWmVDem0N/t7DT8=
=qnhS
-----END PGP SIGNATURE-----



  reply	other threads:[~2007-12-02 15:39 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-02  1:18 RFC: Add ipkg to minimal image Rod Whitby
2007-12-02  3:57 ` Rod Whitby
2007-12-02  8:17   ` [Angstrom-devel] " Koen Kooi
2007-12-02 10:08     ` Rod Whitby
2007-12-02 11:31     ` Richard Purdie
2007-12-02 12:54       ` Holger Freyther
2007-12-02 13:17       ` Koen Kooi
2007-12-02 15:35         ` Koen Kooi [this message]
2007-12-02 17:22           ` Richard Purdie
2007-12-02 19:13             ` Koen Kooi
2007-12-02 18:45       ` Marcin Juszkiewicz
2007-12-02 18:17 ` Paul Sokolovsky
2007-12-02 20:52   ` Rod Whitby
2007-12-03 15:21     ` Leon Woestenberg
2007-12-04  0:07       ` 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=4752D0C5.5080001@student.utwente.nl \
    --to=k.kooi@student.utwente.nl \
    --cc=angstrom-distro-devel@linuxtogo.org \
    --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.