I'm considering creating some dummy packages to solve issues in the Crush experiments. 1. One or two packages (large packages) are only candidates for Crush because one or more binary packages depend on packages we cannot provide in Crush - like adduser or cpp. 2. We *could* do this in the repository but doing that in reprepro is awkward because the entire Depends: line has to be replaced and this means having a dynamic override file. 3. We already replace update-rc.d with a shell version, I'm adding shell no-op scripts to replace dpkg-divert and update-alternatives as well as a shell script to replace fmt with a call to fold. 4. The "base" package for Emdebian Crush is going to be dpkg-crush. (If you don't need dpkg, it's not Emdebian anymore). These replacement scripts have gone into dpkg-crush currently. It would be trivial to modify dpkg-crush to depend on these dummy packages (being no-ops, there would be no installed size effect). 5. There's no chance of implementing adduser or cpp in shell but these need to be packages so that Crush doesn't have to cross-build huge, difficult packages merely to modify the declared dependencies. (Shlibs dependencies always need a rebuild to change, declared dependencies are hard-coded into the debian/control file by the maintainer and relate to commands called within the package instead of library linkages.) An alternative could be that we declare that 'adduser' and/or 'cpp' are blacklisted packages for Crush and if a Debian package is "gripped" using the DEB_BUILD_OPTIONS="usecrush" call, emgrip would remove declared dependencies when rebuilding the package. Not ideal - the package would then fail at runtime - or possibly at install time if the declared dependency is actually intended to support the maintainer scripts. The next version of emdebian-tools (coming soon) will include updated lintian support for checking Grip packages for potential problems in advance of using the packages in Crush. The lintian check can also warn about packages that call the replacement scripts. i.e. the lintian checks are only for Crush compatibility which is more restrictive than Grip compatibility. Therefore a Grip package can easily fail to work with Crush. The wrapper would reprocess the .deb for Crush instead of Grip (or Debian) and run the Crush lintian tests against the result. The package would fail if it still relied on support that cannot be easily removed by emgrip and which would break in Crush. To run the test, a suitable wrapper will be needed to first process the package through emgrip, I'll arrange that. A similar wrapper will be used by svn-buildpackage to build the modified packages for Crush. See also: http://wiki.debian.org/EmdebianCrush (updated) Building 1. svn-buildpackage -us -uc --svn-download-orig --svn-postbuild=/usr/share/emdebian-tools/crush-postbuild.pl 2. upload the native version 3. first chroot to build i386 using apt-get source 4. second chroot to cross build for armel, mips, mipsel and powerpc using emdebuild This method will replace emsource. embug will be dropped too. emdebuild itself can be simplified - there's no real need for much more than the DEB_BUILD_OPTIONS to disable in-build tests and the installation of cross-deps. Even svn-buildpackage can cross-build if the cross-deps exist by passing the -a$arch option down to dpkg-buildpackage. Subsequent releases of emdebian-tools will see about migrating to multistrap support instead of debootstrap for cross-building chroots - that will depend on changes in multistrap in the 2.1.x series. -- Neil Williams ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
Attachment:
pgpnr6gVAcb17.pgp
Description: PGP signature