I've been looking over the lintian source code with a view to implementing some form of lintian support for crossbuilt packages in Emdebian. Common differences between Emdebian packages and standard Debian policy include: 1. Removal of documentation, even those files mandated by Debian policy like manpages, leading to empty virtual packages and empty (or entirely missing) -doc packages. /usr/share/doc should be almost empty. 2. Architecture-checks on all files in ./*/?bin and ./*/lib to ensure that the build has completed successfully without the native compiler being called accidentally (quite common) or due to a patch failure. 3. Removal of all /usr/share/locale/ content unless the package is an Emdebian TDeb. 4. Complete ban on the use of perl in maintainer scripts, including the use of any command that is implemented in perl like update-alternatives, until such time as Emdebian has a C replacement. 5. Complete ban on trying to process any file in a maintainer script that has been removed for Emdebian (like install-info). 6. Checks on Emdebian TDebs to ensure the presence of the POT file in the source, the presence of only .mo files in the package and a ban on empty TDeb packages. 7. No "Essential" tags in debian/control, ever. 8. No unsupported interpreters (python etc.) and no expectation of running /bin/bash - all /bin/sh only (actually must be able to use busybox dash but I'll deal with that on a package-specific basis via the BTS.) 9. Mandatory use of RPATH - any package that has removed RPATH for Debian will find it exists again after a cross build and this is essential. A lack of an RPATH may indicate a crossbuild failure. 10. No attempts to use network access during package configuration - this one is harder but it is important because a lot of embedded devices will have no possible network connection during installation - serial yes, network, no. (Installation media == USB keys or SD cards.) Those are just the top 10. :-) There are probably another 25 that I can think of. Now I'm quite familiar with Perl (all the emdebian build tools are in Perl), I could come up with compatible Perl modules along the lines of Lintian::binaries::Emdebian or Lintian::Cross but I want to be able to fold these checks into the standard lintian checks so that I don't just create a fork that will lag behind lintian and eventually be too incompatible to maintain. (We did that with dpkg-dev and dpkg-cross and it took nearly 10 years to get our changes back into dpkg-dev.) So I'm looking for ideas. I want to be able to selectively disable checks *within* lintian packages - e.g. the RPATH issue - whilst retaining the other checks in that package, modifying the importance of some and adding new ones. Simply disabling the entire set of checks is not worthwhile - I'd have to maintain 90% of the original check file as a fork. I want to be able to do this largely independently of lintian itself so that I don't have to bug you for changes in lintian every time Emdebian makes a new Policy decision. (Emdebian Policy is extremely fluid at this time but will be mostly compatible with Debian Policy within the constraints of an embedded device.) Within the above 10 items, some are even more subtle because if, for example, someone uses Emdebian patches and Emdebian build tools to prepare an i386 package on i386 (e.g. for Eeee PC etc.) then the RPATH issue may disappear and the check would need to revert to Debian behaviour. Necessarily, the actual code running these tests should remain in the Emdebian build tools packages (emdebian-tools) so that these can be maintained without expecting lintian maintainers to test with cross builds. A basic subset of these checks is already implemented in the emdebian-tools build script but wider and more subtle support is necessary, along with proper support for the rest of the lintian checks. It may also be a good idea if Emdebian can modify the importance of various existing lintian checks so that we can downplay errors and warnings that really only matter within the wider Debian context. I don't want to spend too much time discussing the actual checks, I described the 10 above to give some flavour of the extent of the changes and the required granularity of the changes. I'm willing to do the work, all I need from you is some direction and possible means of creating a suitable interface or wrapper. I'm quite happy writing 'emlintian' if I know how it could remain a wrapper without becoming a fork. How could this be achieved? -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: This is a digitally signed message part