ipkg from source

Thanx all for the comments! Some thoughts of my own:

Statement:

Linux packages for handhelds and other embedded systems must be
cross-compiled from source.

Rational:

Handhelds will become more diverse as the use of Linux enabled easy
porting to newer and/or cheaper hardware.

Linux will benefit if new hardware (Xscale?) has complete support as
early as possible in the product release cycle. This is accelerated by a
cross compile environment as it can happen before development systems
are widely accessible.

Cost savings and further penetration as fewer build hosts can build for
more platforms.

Other issues:

hh, emdebian, the autoconf folk etc can all benefit from this effort. We
should build a system that is flexible enough to meet all those needs.

Effort spent in building binary packages is not reused for the next
platform or even the next set of libraries or toolchains on a given
platform.

Effort spent to make a source package cross compile will be reused.
These changes should be pushed upstream whenever possible to save future
work on new upstream versions.

I expect to see complete feeds based on alternative solutions like
uClibc. uClibc now has early support for c++ and pthreads as well as
being more compliant with Posix standards that existing glibc releases.

Cross compile will benefit the platforms with insufficient available
build systems. The issue that will have much more impact is
accessibility of build systems. Most developers do not have access to a
wide range of build systems, but will be able to use and test on cross
compile tools.

It's not a question of mandating cross compiles for developers, it's a
question of insuring the packages support being cross compiled.

Toolchains:

Platforms/feeds should be able to choose which compilers they with to
use. I think arm should move to 3.0.x very soon for example.

Dependencies:

Debian dependency compatibility should be maintained where practical.
Embedded systems need a much more granular set of dependencies than the
base set in debian now, so some will have to change.

In some cases this might do towards individual binaries like /bin/sh or
/usr/bin/ar though we should be able to name them, instead of using the
binary path if desired.

Paths:

Packages should not assume any hardcoded paths. There should be
parameters (env vars?) passed into the build to indicate where to put
staging stuff like libraries and headers for the next packages as well
as where to get the same stuff including kernel headers/source for those
packages that need it.

Native and cross compile tools should be available on the path (natives)
or with something like CROSS=arm-uclibc- environment variables.

I suspect we will want both an ipkg for the target device as well as a
-dev package for the build system or native builds.

Some packages will want binaries in the -dev package. Should they be
named by the host system? Should we build multiple packages? perhaps a
-dev-x86tools etc type naming for these odd balls? Hopefully this is a
small set as binaries needed for development are likely to be portable
scripts.

Signatures:

Sources should be signed by the submitter, and the set of built packages
should be signed by the build host admin(s) for trust reasons. These
should both contain the md5sum of the package.

Commercial involvement:

What happens for the packages that are non-free? Can external folk (read
sun jvm etc) be a part of this system? Perhaps host a build system and
submit binaries? I would suggest that this is the price of entry for
non-free folk.

Tim Riker
Tim@Rikers.org
Tim@Lineo.com
TimR@Debian.org

-- 
Tim Riker - http://rikers.org/ - short SIGs! <g>
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.