I'll get in touch with the Armel Debian guys and see if I can get some assistance converting their DEBs to IPKs.
I'm here to help, just tell me where to focus my attention. If there's any grunt work that needs to be done, manual labor, editing configs, typing tedium, or data entry. I'm your guy. I can work on that between calls.
I imagine the repo will exist mostly for the benefit of developers, and not end users. With a well stocked repo of -dev packages that are compiled to work with the current kernel, there's less risk in damaging the development environment and less work getting the fiddly bits that a programmer might need to get their application off the ground. Less time wasted if Developer A and Developer B both need the same package and end up having to compile the library themselves because there's no existing repo.
Ultimately (way down the road thinking here) we should be able to bake a source once and have it produce both a IPK and a PND package for applications. It'll take a litte work for some packages, but it will be worth it. Most applications won't know the difference if they are in /usr/bin or /mnt/utmp/ and will be happy with just export HOME = `$pwd` It's a win-win.
Hi Mindlord,
I'll get in touch with the Armel Debian guys and see if I can get some
assistance converting their DEBs to IPKs.
Why? That seems like a totally barmy thing to do :-o. Get them to look at OpenPandora specific repo's but don't convert DEB's.
I'm here to help, just tell me where to focus my attention. If there's any
grunt work that needs to be done, manual labor, editing configs, typing tedium, or data entry.
I'm your guy. I can work on that between calls.
Take a look at the open bug list as a starting point (http://bugs.openpandora.org) ;). Patches for outstanding bugs (or even extra info) is always good.
I imagine the repo will exist mostly for the benefit of developers, and not
end users. With a well stocked repo of -dev packages that are compiled to
work with the current kernel, there's less risk in damaging the development
environment and less work getting the fiddly bits that a programmer might
need to get their application off the ground. Less time wasted if Developer
A and Developer B both need the same package and end up having to compile
the library themselves because there's no existing repo.
Yep, that's a fair point (and exactly what I plan to try and achieve). We did have just this at one point before release (with my server hosting the repository).
Ultimately (way down the road thinking here) we should be able to bake a
source once and have it produce both a IPK and a PND package for applications.
It'll take a litte work for some packages, but it will be worth it. Most
applications won't know the difference if they are in /usr/bin or /mnt/utmp/ and will
be happy with just export HOME = `$pwd` It's a win-win.
I am not sure if this is outside your scope of work but the idea of a PND packager for OpenEmbedded has been mooted before (and I started to look at doing just that).
You could look at the IPK packager bbclasses to get a rough idea and you would need to adapt the libpnd recipes to give you -native versions (look at the native bbclasses) so you can run libpnd or at least the builder scripts on the host to actually build up the PND's but I don't think it is actually that big a project, the learning curve is actually far greater than the workload IMHO ;-). You have all the package files nicely segregated in the staging area. The biggest thorn to this is dependencies, that opens a whole massive can of worms.
Regards,
John