More Maverick/EABI fun ;-)

I've just finished cross-compiling an entire root filesystem from scratch for the TS72xx boards with the EABI and it's working out very well! The softfp floating-point ABI has indeed shown a dramatic increase in speed! I've tested out using emqbit-bench and the performance improvements match those found in the article "Why ARM's EABI Matters". I haven't yet been able to try out some hard floating point calculations, such as those done by Martin Guy, but hopefully I'll get to that soon.

The entire HowTo is written up right now and I've tested the procedure with both the arm-softfloat-linux-gnu toolchain/kernel/filesystem and the armv4t-maverick-linux-gnueabi toolchain/kernel/filesystem.

The kernel config /patches are working perfectly for linux-2.6.23.1 . I should have an article up on Gentoo-Wiki.com specifically assisting TS-72xx users in creating a manageable build environment for their boards.

After I get the article up, my next goal will be to determine a suitable binary package manager for live system updates. Thus far, I've looked at Paludis and iPkg [ 20080207 Update: ] and Qmerge which is one of the 'q' tools that comes with app-portage/portage-utils.

After reading an interview with Ciaran McCreesh, I've really gained an appreciation for what Paludis is doing with ebuild syntax modification. Some of those modifications are just so intuitive, convenient, and easily implemented, that I really wish they were already in Gentoo's Portage system. Actually, the article explains in some detail why that isn't already the case.

Paludis also requires a C++ runtime, just because it would have been quite difficult to code it entirely in C, although a rewrite is still possible I suppose. I'd rather not get into C++ right now on production systems. Also it seems that there is still a dependency for the entire portage / paludis ebuild tree to reside on the host, and that is definitely not happening.

On the other hand, iPkg has been in use for quite some time for embedded Linux package management and takes up only a few tens of kilobytes. It's recently been completely rewritten in C, which is fantastic news.

If I were to go with iPkg, then the other issue would be in conversion between Gentoo's tbz2 binary package format and iPkg's .ipkg binary format. Such a converter exists, but still requires some fine tuning.

[ 20080207 Update1: ] I've 95% decided to go with qmerge as my preferred on-board package manager. There are only a few things I need to check out before I go ahead with it fully. Namely, I need to do some test to make sure that it maintains a package database as I would expect, and that it can somehow report exact package versions when told to list installed packages (that might require some work on my part).

[ 20080207 Update2: ] Oh Gawd! Gentoo strikes again... I swear, I've never known a distro that so vagrantly throws around resources as if they were nothing... I think the dependency on /var/db/pkg might have bj@rkskt my idea of using qmerge as an embedded package manager. I'd rather not have to do any feature-adding if i can avoid it... qmerge was 95 percent there... maybe I should just write in some sqlite code and get it over with... I wonder how much that would actually improve things, if at all.

What puzzles me these days about all of the different Linux distro's having different package managers, is that the fundamental issue that they're all trying to solve is the same. Some of them handle that issue better than others, some of them lack certain features that others have, and some lean toward binary package distribution more than others (actually most). Fundamentally, the entire problem lies in solving dependency issues and tieing that together with the package database.

With embedded systems, the size of the package DB has to be extremely small, or else it needs to be maintained off-board.

[ Update 20080207: ] I think that I might be mistaken on the size of the portage db - it's much larger than expected!! For instance du -hs /var/db/pkg/net-wireless/wireless-tools is 128 kB !! That's WAY too big. Maybe I'm looking in the wrong place here - was I wrong to expect an actual database and not a filesystem for recording all of the relevent package information?

RPM & YUM - and why they still suck

I used to use Redhat Linux quite a long time ago - maybe in 1996 - but I was soon after persuaded to switch to Slackware Linux. Why? Redhat's package management system, RPM, is a piece of crap.

What I used to hate about RPM a long, long, time ago:

1. "Dependency Hell", as it is so dearly termed by many Redhat users, is when one is unable to install a package because of the exponential number of dependency packages that are necessary. The simplest way to avoid this is with the "nodep" option, but then missing dependencies become horribly difficult to trace.
   
   
2. The inability to optimize or select which dependencies (--configure options) will actually be present on your system. For example, --without-alsa / --with-oss . The simple answer is - support everything, except what Redhat doesn't want to, and make the dependency tree static. This could easily be worked around by compiling all of your own sources from scratch and populating your own RPM repository, but then that defeats the purpose of RPM in the first place, unless you're intending on releasing a new distro or creating a kickstart script so that the Redhat install CD would pull rpm's from a specific location.
   

I couldn't really blame Redhat at the beginning, because they were basically the first large-scale commercial Linux distribution around, and they've probably brought more to Linux than any other Linux distribution, aside from Debian maybe.

Now though, I feel as though I can blame them. The complaints that I have, are still basically the same. After over 10 years, there has been no evolution with RPM aside from this lovely thing called yum which sorts out dependencies and retrieves files as necessary.

I'm currently packaging the sun jdk, naturally without source code so that i comply with Sun's BCL or whatever. When I built this RPM and tried to install it with RPM, i got an error saying:

Error: Missing Dependency: libodbc.so is needed by package jdk
Error: Missing Dependency: libodbcinst.so is needed by package jdk

After some amount of frustration and searching incoherent sites for documentation on .spec file creation (required for building RPM's) I found the following option, which I thought was like the heavens opening up. I now quote from http://www.rpm.org/max-rpm-snapshot/s1-rpm-depend-auto-depend.html, which seems to be as authoritative a site on .spec file creation as any.

The autoreqprov, autoreq, and autoprov Tags — Disable Automatic Dependency Processing

There may be times when RPM's automatic dependency processing is not desired. In these cases, the autoreqprov, autoreq, and autoprov tags may be used to disable it. This tag takes a yes/no or 0/1 value. For example, to disable automatic dependency processing, the following line may be used:

AutoReqProv: no

The autoreq and autoprov tags can be used to disable automatic processing of requirements or "provides" only, respectively.

After inserting this magical line into my .spec file, and packaging the file without any issues, even installing the rpm file, without any issues, yum still provides me with the fantastic error code above, even when the rpm itself says that it has no dependencies.

Go team!!