Differences between revisions 2 and 3
Revision 2 as of 2009-03-05 12:04:16
Size: 2993
Editor: NeilWilliams
Comment: adding some detail
Revision 3 as of 2009-03-16 03:35:06
Size: 2993
Editor: anonymous
Comment: converted to 1.6 markup
No differences found!

How to audit Emdebian packages and patches

Aims of the audit

  • incorporate as much of the current patch set into the Debian package as possible before the freeze starts for squeeze.
  • retain only those patches that are essential for achieving the small installation size of Crush.
  • identify all functional changes in Crush packages and investigate the advantages and disadvantages of those changes.
  • use DEB_VENDOR support to implement these changes, if possible.
  • improve emdebian-tools to make cross-building Debian packages easier.
  • as a result of all the above, allow Crush to be available for multiple architectures in squeeze.

Participating in the audit

  • You need emdebian-tools (>= 1.5.1) and you need to be running Debian Sid - install emdebian-tools from Debian, run apt-get update and apt-get dist-upgrade to upgrade from 1.5.0 to 1.5.1. A chroot is NOT suitable for audit purposes but packages should still build using the cross-building chroot, i.e. using empdebuild.

  • Any toolchain will do - except ARM because the build dependencies for ARM no longer exist in Debian.

  • Use emsource -c $package for each untagged package in the table above. Always ensure you refresh the build directory with emsource -c before starting on a package.

  • Identify all changes in the patch files that change the functionality of the final package. i.e. anything that results in a different compiled binary compared to using the standard Debian package and removing some files.
  • Tag each package in the table listing using the legend below the audit table.

Routine builds for armel, i386, mips and mipsel will only start once all packages subject to the audit are tagged and all functional changes have been identified. Even then, decisions will need to be made on how to best implement the functional changes before the autobuilder will be restarted.

Tagging packages

  1. Packages that do not cross-build always have a Status of Wait - packages that fail to cross-build should also be tagged tools to indicate that other changes may be needed.

  2. No new bugs are to be filed under the long term mass bug filing for cross-build support until the Audit is complete for that package.
  3. Every time you view a package as part of the Audit, check for functional changes and tag the package appropriately and freshen the patches to leave the removal of documentation etc. to the post-processing done by Grip. i.e. patches must not duplicate the effect of emgrip.
  4. Clean up and update all existing patches by removing any change that has already been included etc.
  5. Add xcontrol tags if an emdebian-xcontrol.patch exists in any form after cleaning up the patches.

  6. The principal aim is identification of functional changes and refreshing all patches. Some packages have not been rebuilt since the very earliest builds for Crush.


CategoryEmdebian