[oe] ipkg/opkg offical response

Richard Purdie rpurdie at rpsys.net
Thu Mar 27 17:17:29 UTC 2008


Hi,

The core team has been discussing various issues at length. On the
opkg/ipkg issue the official position is that:

a) the commit was badly thought out
b) we need to document procedures for making changes
c) there should be no more infrastructure changes until documentation on
   the process is written and agreed[1]
d) the commit won't be reverted due to the reasons below
e) we agree some method is needed to select between ipkg and opkg ASAP
   to fix the damage that was done. 

Why not outright disapprove the revision?:

* Its been in too long, we needed to have acted quicker, now we'd need 
  some setup to handle reverting it properly and safely.
* The changes to meta-toolchain and packaged-staging.bbclass 'ok'
* rwhitby added now added a partial solution to address some of the 
  issues (thanks!)

Where do we go from here?

I think Marcin has a nogpg version opkg he will commit so people don't
have any issues with the increased size of ipkg. Does that and rwhitby's
symlink fix address everyone's concerns? If not can we document the
remaining issues and then hopefully address them.

Do we need something to select between opkg and ipkg or is everyone ok
with the symlinks?

OE management is more than aware there is a problem. The underlying
issue is we can't even seem to agree on how we make decisions :(.
Various topics are under discussion but until we solve that one I doubt
we can move forwards on anything else...

[1] There is work still in progress on packaged staging and I'd like to
propose that we see the packaged staging changes through to completion.
Off the top of the head there are the following remaining changes:

* Adding do_deploy to packaged-staging's knowledge. This is best done
with the patch for kernel.bbclass that thesing was been working on. I've
made some suggestions for tweaks (looking at the version already in
poky) and suggested he commits it after that.
* Fixing the problem with autotools_stage_all and multiple libraries of
the same name. We know what the problem is, we're just not sure of the
best way to fix it. This isn't any disagreement, just us (mainly me) not
wanting to change anything too much more in case it breaks again...

Regards,

Richard (on behalf of the majority of the core team)






More information about the Openembedded-devel mailing list