Re: [oe-commits] org.oe.dev rootfs_ipk: as per OE, policy: remove feed management tools

[Richard Purdie <rpurdie@rpsys.net>]

On Sat, 2007-03-03 at 18:19 +0100, Matthias Hentges wrote:
> > Rod Whitby schreef:
> > > Stelios Koroneos wrote:
> > >> I am not sure how many of you are building multimachine distro's but the old
> > >> system was not a very good solution.
> > >> We are building a distro for a number of machines x86 arch (i486, i585,
> > >> i686), a number of powerpc targets  and recently mipsel and puttinng
> > >> everything in a giant ipk pool is not the best of solutions.
> 
> 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...

> Correct again. It is however my _personal_ experience that
> multi-machine.bb causes more problem than it solves (of course YMMV).
> Most of them are caused by faulty/problematic package .bb's (not OE or
> ipkg bugs) but IMO these errors are very hard to catch and it is almost
> impossible to review all 4336 .bb's currently residing in OE.
>
> The only way to build clean and (almost) guaranteed-working feeds is to
> build each MACHINE in its own tmpdir. You'll get many duplicated
> packages for sure but the feed will be consistent.

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

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

Regards,

Richard