From: Thomas Lundquist <lists@zelow.no>
To: buildroot@busybox.net
Subject: [Buildroot] buildroot with ipkg
Date: Thu, 20 Sep 2007 23:37:24 +0200 [thread overview]
Message-ID: <20070920213724.GA18637@zelow.no> (raw)
In-Reply-To: <46F2E33A.1070307@free.fr>
On Thu, Sep 20, 2007 at 11:16:42PM +0200, Julien Boibessot wrote:
> >
> Well I 'm not sure it's a good idea to let the user mix "builtin" and
> "packaged" software.
> If he choose to use ipkg, or another method, then all the Buildroot
> utilities he wants to have in its rootfs should be packaged with the
> selected method and then installed in the TARGET_DIR, just before
> creating the (jffs2/ext2/...) rootfs image.
Why bother then? if all that will be done is putting it where everything
is today? Then it's no need to make packages at all.
My whole point is that buildroot has a base and then added packages,
what to have where is up to the one building it and when / how to add up
to the builder and user. wget and install, nc and install, USB stick or
whatever.
> That's what they do in OpenWrt and I think it's a good idea:
> * build the selected utility/package
Done.
> * install it in a custom directory, instead of TARGET_DIR
Done. TARGET_PACKAGES_DIR
> * "ipkage" it from that directory
Done with tar.* and .udeb right now, ipkg is coming.
> * install the generated "xxx.ipkg" in TARGET_DIR
This is where I lost it. it's up to the end user to do this step. This
is why I do autonomous packages.
> That way your system is always aware of the installed packages even if
> you flash a complete rootfs (I'm speaking of the ipkg case which is the
> only one I have studied yet).
a very much bigger rootfs than needed.
> After flashing, you can even removed
> packages directly from your target.
why not add them instead of removing? make a leanser rootfs and a user
able to choose what to use his valuable RAM/Flash on.
Feel free to to this and I'd be happy if there was a patch to choose
this method but no way am I going to make this the only one. The builder
should be able to choose what to put where.
Thomas.
next prev parent reply other threads:[~2007-09-20 21:37 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-17 12:09 [Buildroot] buildroot with ipkg pasteur
2007-09-17 19:44 ` Julien Boibessot
2007-09-17 20:14 ` Erik Andersen
2007-09-17 21:17 ` Julien Boibessot
2007-09-19 6:42 ` Thomas Lundquist
2007-09-19 12:17 ` Thomas Lundquist
2007-09-19 19:27 ` Bernhard Fischer
2007-09-19 20:56 ` Thomas Lundquist
2007-09-19 21:50 ` Bernhard Fischer
2007-09-20 21:16 ` Julien Boibessot
2007-09-20 21:37 ` Thomas Lundquist [this message]
2007-09-22 21:28 ` julien.boibessot at free.fr
2007-09-22 21:43 ` Bernhard Fischer
2007-09-22 22:19 ` Thomas Lundquist
2007-09-20 9:06 ` Elizabeth Oldham
2007-09-20 10:52 ` Thomas Lundquist
-- strict thread matches above, loose matches on Subject: below --
2007-09-22 22:28 Thomas Lundquist
2007-09-23 20:43 ` Bernhard Fischer
2007-11-14 10:12 ` Thomas Lundquist
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=20070920213724.GA18637@zelow.no \
--to=lists@zelow.no \
--cc=buildroot@busybox.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox