Following on from the update of the audit, I've been testing an idea for Crush. 1. Where packages are not intended to have functional changes as a result of merely cross-building, Crush should take packages directly from Grip and not cross-build them at all. It's a waste of effort when Grip has already achieved 99% of the possible size reduction for the packages concerned. 2. Crush only takes those architectures that overlap between Grip and Crush - i.e. ones for which Emdebian has toolchains to fill in the gaps. 3. Much like Grip, Crush would have a 'pkglist' filter file which dictates which packages are updated from Grip. Unlike Grip, this list is more or less static and only updated manually. The actual process of updating the packages specified in the list would be automated. 4. Patches in Emdebian SVN for packages in this list will not get updated with new Debian releases of the affected packages. (The only reason to have patches for such packages is so that a cross-build avoids parts of the build that fail like python bindings or documentation builds - i.e. the patches themselves are broken by design.) This is the hard part because it is the only way to manage the workload, yet it is also going to block cross-builds of affected packages. Note that allowing the python-bindings does not add python to the dependencies of packages not already containing python bindings. Indeed, the packages containing the python bindings can and would still be excluded from the updates into Crush. The pkglist is per binary package and, as ever, sources are migrated unchanged. Merely having a particular source package in Crush does not mean that every binary package produced by that source in Debian would also be in either Grip or Crush and some of the ones in Grip will not make it into Crush. Overall, the range of packages in Crush doesn't change from 1.0. 5. Crush remains small (< 1,000 packages eventually, currently my tests have only 811), so although this could seem like duplication, keeping the same package files in crush/pool and grip/pool isn't that much wastage. (300Mb on my test, ~500 packages but not all of the packages in Crush are currently in Grip.) 6. Grip gets extended to include packages that were formerly only in Crush (like a full GPE environment). Equally some packages that were in Crush 1.0 are no longer in Debian Squeeze, so there are (or would be) missing dependencies elsewhere. The other way to do this would be to somehow fold Crush into the Grip repository - whereas that would be easier for the server it would not be easier for the users or the machines. Packages.gz files in Grip are smaller than in Debian but are still a lot bigger than the equivalent ones in Crush would need to become. There might be a complex way of having Crush as a codename within Grip but I'm not sure it is worth doing. Finally, despite how this may sound, this does NOT mean that Crush is going to make it alongside Squeeze. The remaining issues are smaller but still far from trivial. What this update and the experiment achieve is the removal of quite a large set of packages (some easy to build, some that were quite hard to cross-build for 1.0) at the expense of leaving a hard core of complex and difficult ones that still need to be cross-built. Before those even can be cross-built, there needs to be further work on just how the problems can be solved. The problems haven't changed, the issues haven't become easier - this experiment might just mean that the problems affect a lot fewer packages but the problems are as intransigent as ever. :-( However, most of the issues are to do with being able to cross-build a package at all rather than architecture-specific issues. Therefore once the problem is solved for a particular package, the package could be cross-built for multiple architectures because there are so many fewer packages needing to be cross-built. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgp4x8tjKzpfT.pgp
Description: PGP signature