OESF | ELSI | pdaXrom | OpenZaurus | Zaurus Themes | Community Links | Ibiblio

IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
> Authoritative Ports Collection?, Do we have one? Why not?
maytagman
post Mar 23 2006, 08:07 AM
Post #1





Group: Members
Posts: 24
Joined: 15-March 06
Member No.: 9,366



Hey all, I'm just thinking of ways to make pdaxrom's use even more simpler for the less linux-savvy amongst us, and my mind wanders to package management.
There are quite a few packs available to us as it stands, but the pdaxrom's 'feed' system has a pretty limited selection. When I use a major distro like Debian or NetBSD, I have a huge ports collection to choose from. Granted, theres a lot less people making packages for our Zs, but still. I don't understand why we are using seperate packaging process for different OS flavors on the Z. We are all on the same platform, we should all decide on one package format and pattern to use so we have more options. So, a few questions

1) Can packages from OZ, etc be installed under pdaxrom? Or are there too many differences between the varying kernels to make this possible? If so, what are the differences, and how can we equalize them to play nicely with eachother?

2) So, pdaXrom uses ipkg, OZ uses what? Can we cooperate on a ports collection compiled for the xscale/arm architecture as opposed to specific builds?

3) Will precompiled binaries for previous xscale/arm builds on distros like debian/gnu's ports collections function with our machines?

4) I understand there is a debian/gnu variant for the Z, will its apt-get draw from debian's ports collection? If so, then I don't see why we can't get them to work under pdaxrom.

5) Is the pdaxrom feed the authoritative package source right now? I know there are about 9000 personal package collections out there, why arent these consolidated? Is it a question of bandwidth and serving? What is the hold-up here?

My Zaurus nirvana is a land where everyone is cooperating for maximum compatibility between each other. I know there is some spirited rivalry between pdaxrom and OZ-land, and that's fine. However, I think it's best to realize that we all run the same niche hardware, and we might as well try and give ourselves as many package choices as possible. My dream would be simply apt-get'ing from the Z and having it just plain work.
Go to the top of the page
 
+Quote Post
Hrw
post Mar 24 2006, 01:41 AM
Post #2





Group: Members
Posts: 1,376
Joined: 11-January 04
From: Poznań, Poland
Member No.: 1,413



1. OZ packages will rather do not work under pdaX - need newer glibc and newer other libs. In OpenZaurus we also use 2.6 kernels on clamshells which change many other things in userspace apps.

2. OZ use C version of ipkg, pdaX use old shell implementation (hacked in many ways)

3. It depends - OZ is soft-float (see other thread what it means), Debian is hard-float - so Debian packages will not work under OZ. Do not remember how it is with pdaX. Of course I'm talking about using Debian packages with OZ or pdaX not about running Debian chrooted.

4. Debian/ARM can be used on Z but it was never supported as native distro for Z. See PocketWorkstation project (iirc they worked to get Debian on Z without other distro).

5. PdaX feeds are split into official one (build by pdaX maintainer) and contributions by external developers.

I'll skip rest of things now.
Go to the top of the page
 
+Quote Post
0xDEADBEEF
post Mar 24 2006, 01:49 AM
Post #3





Group: Members
Posts: 52
Joined: 4-December 05
Member No.: 8,660



pdaXrom uses gcc 3.4.5-xscale-softvfp compiler. So I guess it must be softfloat.
(does it mean that float math is done by compiler libs? in that case how is hardfloat handled? real fp opcodes in code emulated by kernel?)

Marcin: a tak przy okazji to czesc ;-)
Go to the top of the page
 
+Quote Post
koen
post Mar 24 2006, 02:16 AM
Post #4





Group: Members
Posts: 1,014
Joined: 4-January 05
From: Enschede, The Netherlands
Member No.: 6,107



QUOTE(0xDEADBEEF @ Mar 24 2006, 09:49 AM)
pdaXrom uses gcc 3.4.5-xscale-softvfp compiler. So I guess it must be softfloat.
(does it mean that float math is done by compiler libs? in that case how is hardfloat handled? real fp opcodes in code emulated by kernel?)
*


If you are using the old ARM ABI you can only have one form of binaries in your system: softfloat ones or hardfloat ones. You can't mix them.
The answer to "how is hardfloat handled" is: real fp codes trapped by the kernel.
This arrangement sucks, so ARM ltd. invented EABI where you can mix softfloat and hardfloat stuf without problems. That means you can use your vfp or crunch coprocessor for floatintensive applications and let the rest use softfloat.
Go to the top of the page
 
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 29th November 2014 - 01:35 AM