From: Matthias Hentges <oe@hentges.net>
To: openembedded-devel@lists.openembedded.org
Subject: Re: [oe-commits] org.oe.dev rootfs_ipk: as per OE, policy: remove feed management tools
Date: Sun, 04 Mar 2007 01:08:20 +0100 [thread overview]
Message-ID: <1172966900.11398.124.camel@localhost.localdomain> (raw)
In-Reply-To: <1172962072.5942.68.camel@localhost.localdomain>
Am Samstag, den 03.03.2007, 22:47 +0000 schrieb Richard Purdie:
> On Sat, 2007-03-03 at 18:19 +0100, Matthias Hentges wrote:
> > > Rod Whitby schreef:
> > > > Stelios Koroneos wrote:
> >
> > Ahh, finally someone with _real_ arguments in favor of the change. I do
> > feel your pain, I really do. I can see that the change makes life easier
> > for multi-machine / multi-arch builders. I don't have any problems with
> > that at all, only with the way it was implemented.
>
> Technically a giant pool of ipks should work and if it doesn't it points
> at bugs that need fixing.
>
> Equally, I don't mind having splitting implemented as per my last mail.
> Lets not try and brush ipkg bugs under the mat though...
Using a very large ipk feed does indeed work nicely to generate images.
However, generating Packages can take ages ( and so do image rebuilds
because of this ). That's about the only problem I see w/ One Giant Feed
> My personal experience says multimachine works well and I use if for
> everything as standard these days. Have you any specific examples or
> problems? I have been dealing with them as and when I've seen them but I
> haven't seen any in quite a whiie...
I wasn't exactly running into real ipkg bugs. I had problems with
packages using machine-specific stuff for some models ( say all
sl-c3x00) and hence having their ARCH set as $MACHINE, but not for other
models ( like collie, poodle ) having their ARCH set as $ARCH.
It's a packaging bug, not an ipkg bug but annoying in any case ;)
> > > Rootfs generation continued to work.
> > > However, rootfs_ipk.bbclass is *not* the place to put in feed management. That class is
> > > supposed to build a rootfs from ipkgs, which it does by treating deploy/ipk/<arch> as
> > > feeds. I can think of ways to do rootfs generation without Packages.* (e.g sqlite), and if
> > > they prove to be faster and more robust I _will_ replace the old methods.
> >
> > The current feed-style "installation" of the rootfs has the huge
> > advantage of checking the feed for broken packages at _image-generation
> > time_.
> >
> > Removing this important check will likely cause endless pains to feed
> > and distro maintainers for barely any benefit.
>
> I must admit I fail to see what's wrong with the current image
> generation methods. Yes, we can optimise some of it further but its not
> that bad at the moment. If you don't like ipkg, you can also do it using
> apt now...
Exactly.
next prev parent reply other threads:[~2007-03-04 0:10 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-02 1:14 [oe-commits] org.oe.dev rootfs_ipk: as per OE, policy: remove feed management tools Andy Wilcox
2007-03-02 8:22 ` Stelios Koroneos
2007-03-02 9:25 ` Rod Whitby
2007-03-02 10:00 ` Koen Kooi
2007-03-03 17:19 ` Matthias Hentges
2007-03-03 22:47 ` Richard Purdie
2007-03-04 0:08 ` Matthias Hentges [this message]
2007-03-04 10:42 ` Richard Purdie
2007-03-02 9:47 ` Koen Kooi
2007-03-03 19:22 ` Richard Purdie
2007-03-04 8:43 ` Koen Kooi
2007-03-04 10:59 ` Richard Purdie
2007-03-04 11:31 ` Koen Kooi
2007-03-04 14:49 ` Matthias Hentges
2007-03-04 15:01 ` Koen Kooi
2007-03-04 15:10 ` Øyvind Repvik
2007-03-09 10:54 ` [RFC] bogofeed creation Rod Whitby
2007-03-09 11:12 ` Richard Purdie
2007-03-09 13:13 ` Rod Whitby
[not found] <E1HMgkl-0004SM-Gs@linuxtogo.org>
2007-03-01 15:55 ` [oe-commits] org.oe.dev rootfs_ipk: as per OE policy: remove feed management tools Michael 'Mickey' Lauer
2007-03-01 16:23 ` Koen Kooi
2007-03-01 17:21 ` Hans Henry von Tresckow
2007-03-02 0:07 ` Hans Henry von Tresckow
2007-03-02 0:17 ` Richard Purdie
2007-03-02 0:39 ` Rod Whitby
2007-03-02 0:33 ` Matthias Hentges
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=1172966900.11398.124.camel@localhost.localdomain \
--to=oe@hentges.net \
--cc=openembedded-devel@lists.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox