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