-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said:
|> ---2 "building with a cross-compiler is wrong, builds should be done |> natively in an emulated (qemu) arm environment" |> Can Openmoko switch to compiling arm binaries 'natively' in a qemu |> environment, like Ubuntu Mobile? | | Again, what's the exact problem description here? Cross-compilation is not | "wrong" at all, it works very well. By compiling in environments like | Scratchbox or Qemu we give away a lot of flexibility and scalability. | It will kill performance and the end result (as in the flashable image) | does not differ at all. So, where would be the potential benefit? The potential benefit is no more recipes or cross build workarounds. ./configure just does the right thing. It has to be slower though, how much I dunno. Personally I like cross alright, but qemu "native" is a valid solution too. |> ---3 "Openmoko should use normal .deb or .rpm packages, instead of |> ipkg/opkg" |> This usually includes people saying we should use src rpms / debian |> src files to build packages. | | That's actually two different questions and I can only comment on one: | | 3.1. What's the actual problem here rather than a desperate attempt to | unify the desktop and the embedded world more than what's good for | the embedded world? Is it that .ipk are less known than .deb? Is it | the feature of the command line tools or the packaging system per se? See the end for a rant on this. | RPM? I have yet to see a version of RPM that is working at all (not | considering performance) on an embedded system like the Neo. Until | then we should not even talk about that as a viable option. There's nothing wrong with RPM for this. Official RPM builds against sqlite libs now if you want, and I wrote a version for busybox that is even lighter, using package headers stored in /var/lib/rpm to know what is installed and its metadata. And from my side -- nothing wrong with .deb either, RPM and .deb do the same thing about as well. | 3.2. I have no experience with building from source packages other than | tarballs. Maybe someone else can comment on that. Well it's a funny one to deal with, but the non-cross qemu method actually allows them to do that with no hassle. | Moblin as in patches and applications is a different story, we should talk | about that on openmoko-devel, however my first impression is we would give up | a lot of flexibility by locking people in to one environment. The openness of | Openmoko depends on a large part on the availability of OpenEmbedded. Without | OpenEmbedded it will be much harder for people to come up with own | experiments based on the Neo hardware. | | I hope that clarifies some things and gets the discussion started, if | necessary. I want to say about that "flexibility of OE". I am haunted by a sense of failure and distress this last week or so. Wolfgang said "build DM2 with bitbake, put it in git or somewhere else and start patching it.". I can barely half-build the thing anyway, god help me pkgconfig, but I studied the OM Wiki that talks about using bitbake, I didn't find any examples to copy. When I googled one and fiddled with it, the Fedora package for bitbake just said something about demanding to set a CACHE variable, I look in the config file and see a ton of crap I have no idea about. man bitbake shows me a shell prompt. I look at what is in the package, I find info stuff in /usr/share. I read two whole pages about how great bitbake is, nothing about CACHE. $ grep CACHE /usr/share/doc/bitbake-1.8.8 $ Bah I have to try to cook the thing and its dependent libs by hand with a shell script. Now one can say ha you clueless N00b any fule know you have to blah blah, but I say to myself, if this was RPM or .deb based I would have googled out an answer and gone on. I can and do use RPM for normal and cross packaging -- actual packaging, not just using the packages -- just fine, I don't think the issue is I am particularly inbred. The other things that bother me about OE are the lack of SRPM type source capture -- critical feature for license compliance -- and the epileptic-fit inducing problems with -devel type include / libs packaging, being able to pass around and host-install cross-devel packages to cross compile other packages against easily. If I use RPM or .deb I get grown-up support for this. - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkgF9z4ACgkQOjLpvpq7dMr+KwCdFLMopE5ombRroSHN/mneURp/ EBMAn2eWQie+bGjoPX3nn8JNHrZEBYN6 =i85L -----END PGP SIGNATURE-----
