[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Why are we cross-compiling Debian?

OK, this is a radical thought - one of those light bulb moments and the
light may actually be from an oncoming train but - why are we
cross-compiling binaries that are already available as native binaries?

1. Emdebian is Debian stripped-out - a smaller Debian for smaller
2. Emdebian has always sought to use the best of Debian - we may be
missing a trick by *not* making the best use of one of Debian's most
powerful features: the buildd system.
3. Emdebian is supporting the same architectures as Debian supports
upstream, just the devices are smaller.
4. It's been staring us in the face since the creation of dpkg-cross.

The idea is this: If we are proposing to cross-compile binaries that
already exist as native binaries in Debian, we had better have a *very*
good reason. I'm thinking that optimising binaries for size may not be
sufficient cause and may actually be making a rod for our own backs.

Rebuilding binaries can only ever introduce new bugs - at best it
leaves us with no extra bugs, at worst existing bugs in the package can
cause the cross-build to fail.

How much space will optimising binaries for size really provide? How
does that compare with the simplicity of having the same arch-specific
binaries (with the same md5sum) in Emdebian and Debian? Is optimisation
just going to be a source of emdebian-specific bugs? (There was a nasty
bug in perl on hppa that came down to an optimisation change. These
bugs can be very hard to pin down.)

How does that compare with the amount of space saved by simply removing
docs and customising locales but leaving the binaries untouched?

dpkg-cross doesn't recompile, it simply moves files around within
the .deb.

Why can't Emdebian do the same?

Maybe we've been so used to cross-compiling and so centred on the
source code that we've forgotten the higher level?

The process could be:

1. apt-cross --get package
2. Unpack the .deb using ar and tar (see deb-gview for the C code)
3. Remove the docs (simply delete AUTHORS, README, NEWS, ChangeLog etc.
and remove the md5sums from the .deb control data).
4. Transform the localisation using emlocale
5. Leave the binaries untouched - literally.
6. Modify debian/control to our needs (remove doc packages, include the
locale packages)
7. dch -v $emdebian_version
8. Put the debian/* changes into SVN and the .diff.gz
9. Rebuild the .debs - *retaining* the arch-specific filename.

Step 9 is where we differ from dpkg-cross and it is only a matter of
retaining the _arch instead of outputting package-arm-cross_$vers_all.
foo_2.3.0-1_arm.deb becomes foo_2.3.0-1em1_arm.deb only smaller.

This could be done automatically - we could process the entire archive
in this way in a fraction of the time required to cross-compile the
entire Debian archive for multiple architectures.

It would make synchronising with Debian a doddle.

This method is architecture-neutral because we won't be changing the
arch-specific components of the .deb so any arch can generate
emdebian .debs with the immense benefit (AFAICT) that we can
emdebianise our own systems in order to fix bugs on the target systems!

Yes, the emdebian package would replace the debian one instead of
sitting alongside but it's the same binary on the same arch. The next
apt-get upgrade and the debian package is replaced. Alternatively, run
a mixed system were some packages come from Debian repositories and
others are updated from emdebian stripped packages in our repository.

The only bugs introduced by this process would be location bugs - the
binaries not being able to locate arch-all files. That's easy to fix.

Are the benefits of cross-compiling really so huge that we *have* to go
that way? It is a huge amount of work - we ought to be sure it is
actually necessary.

We can still cross-compile certain emdebian-specific code but even that
may be better off within Debian itself.

OK, I know, I've missed something here, there must be a problem in this
idea - I just can't see it yet. It can't be this simple - can it?


Neil Williams

Attachment: pgpKN1lkexEqU.pgp
Description: PGP signature

Reply to: