Author Topic: Authoritative Ports Collection?  (Read 3587 times)

maytagman

  • Newbie
  • *
  • Posts: 24
    • View Profile
Authoritative Ports Collection?
« on: March 23, 2006, 11:07:40 am »
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.

Hrw

  • Hero Member
  • *****
  • Posts: 1366
    • View Profile
Authoritative Ports Collection?
« Reply #1 on: March 24, 2006, 04:41:13 am »
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.
OpenZaurus 3.5.4x Release Manager
OpenEmbedded, Ångström, Poky developer
My website

Misc embedded hardware.

0xDEADBEEF

  • Jr. Member
  • **
  • Posts: 52
    • View Profile
Authoritative Ports Collection?
« Reply #2 on: March 24, 2006, 04:49:07 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?)

Marcin: a tak przy okazji to czesc ;-)

koen

  • Hero Member
  • *****
  • Posts: 1008
    • View Profile
    • http://dominion.thruhere.net/koen/cms/
Authoritative Ports Collection?
« Reply #3 on: March 24, 2006, 05:16:38 am »
Quote
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?)
[div align=\"right\"][a href=\"index.php?act=findpost&pid=120060\"][{POST_SNAPBACK}][/a][/div]

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.
Forums are not bugtrackers!!! Smart questions
Ångström release team
iPAQ h2210, iPAQ h5550, iPAQ hx4700, Zaurus SL-C700, Nokia 770, all running some form of GPE
My blog