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 devices. 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 ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpuK5OqjtX3c.pgp
Description: PGP signature