On Sun, 28 Mar 2010 11:15:09 +0200 Simon Richter <sjr@debian.org> wrote: > > This only works with a small number of packages, as per my email about > > the experiments with Crush. > > Would it make sense to specify that Crush autobuilders set DEB_VENDOR to > "emdebian"? Already set as "emdebian-crush" - see /etc/emvendor.d/emdebian-crush.conf However, this is used AFTER the build to specify the options to emgrip. Besides, there will be only one Crush autobuilder. I'll build them on this box. > Currently, that doesn't make much difference with existing > packages, but we'd be able to merge changes back into Debian by letting > them look at DEB_VENDOR. The level of changes is too large. I've test built the first four packages and there are some issues: 1. The temptation to remove EVERYTHING that Crush cannot support is overwhelming. No point building stuff that emgrip is going to throw away. This also makes the builds faster which is very important during testing and experimentation. e.g. dpkg only needs to change coreutils to busybox but there's little point leaving the dpkg-dev build and that means removing the perl build deps . . . it also means keeping the experimental packages closer to what we knew worked as Crush 1.0. 1a: I'm going to try and reign that in, later, maybe. 2. The same problems recur with Crush 1.0 - we have to remove or avoid stuff that simply won't cross-build, like python. As there are so few packages involved, that isn't too bad. 3. Changing the source package name causes huge numbers of changes that are simply incompatible with the normal packaging - renaming all the .install files, the package name needs to be changed in the debian/changelog, there need to be adjusted Provides: Replaces: Conflicts: in debian/control, symlinking the .orig.tar.gz... 4. I haven't decided yet how to implement the replacement for debian/xcontrol. I'm thinking of something based on multistrap code to simply download a hard-coded list of build-depends and pass those to dpkg-cross. i.e. not using apt-cross at all. > Apt already handles (by ignoring) multiarch qualified builddeps, not > only dpkg and dak are missing as the major roadblocks to getting cross > builddep information into the archive -- however that is only useful for > squeeze+1. I don't see how that helps. Are you thinking too far ahead to a time when Crush will be more than a sideline and experiment - a time when Crush can be based on a fully working multiarch base? (i.e. Crush 3.0 or possibly 4.0, not the current experiments.) -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgp2lTsQbPNT5.pgp
Description: PGP signature