http://www.emdebian.org/emdebian/emdebian.html "managing dependencies such that Emdebian remains buildable at all times will require care. A preliminary build of 550 packages with glibc has shown that the problem is manageable. Ensuring that build-depends are honoured for migration of a source package into Emdebian (unlike Debian proper's migration policy from unstable to testing) should help; so will keeping the total number of packages much smaller than Debian's." My first thought on build-depends is always pbuilder but I must admit, I don't know a whole lot about bootstrapping and base packages, so I'm looking to learn. Where is that preliminary build? What was learnt from it? How up to date is SLIND? What would it take to update it to current Debian unstable versions and the emdebian composite method? Do we need a new version of pbuilder that knows about the emdebian changes to essential or do we have such a thing already? From a very cursory test with pbuilder --include --exclude options, it does seem that we at least need a base set of packages that are rebuilt without certain dependencies, especially if we are to remove perl from the list. I guess that flows naturally into the next question: What are the steps necessary to identify the initial Emdebian subset of Debian? I'm looking at GPE for arm as the top-level requirement, the question is really what do we need below that as the smallest possible package set to install? I'm thinking of a chroot / bootstrap routine that would use the emdebian target repository to determine the dependencies in such a way that emdebian could require that new packages to be added to the emdebian target repository *must* build with that tool in order to ensure that the emdebian target archive remains buildable - our version of FTBFS. Such a tool may also be able to then act as a buildd to create packages for other architectures. (I build on amd64 for arm, the buildd (i386) may have to build that for m68k?) I've only dabbled in this area so far - trying to write a program that identifies a 'path' through these dependencies so that if we want Gtk, we can identify which packages need to be built before Gtk, all the way back to libc6. So far, I've got empath [1] but it's very limited. My theory is that this will update the path as each level is built so that every package in the repository can always be built. A missing dependency at any point would be equivalent to a FTBFS bug in Debian, similar severity, similar importance. Now, we could just use dpkg-cross -A to force the intermediary packages into place, build Gtk and be done but whereas that is practical for testing the cross-build, it isn't going to help the archive remain buildable. The reason I'm looking at a chroot is that I can't build apt on this system without a chroot so I can't investigate a cross-build of apt without an emdebian chroot. I've got some Gtk1 applications that I'm trying to move to Gtk2 and one depends on libgnome-dev which in turn depends on libdb3-dev. apt depends on libdb4-dev (IIRC) which conflicts with libdb3. :-( I've also thought about investigating building 'apt' within OE so that existing users of OE / Familiar have a possible upgrade path - install an .ipk of apt using normal OE ipkg feeds, that copy of apt would be pre-configured to look at the emdebian repository and the user could start a dist-upgrade. The apt documentation does insist that it must be possible to reconstruct the apt cache data from the files that exist on the system so it may only be a case of generating a dpkg status file from the ipkg status file. Should be interesting! What are the chances of that working? :-) (I'm just trying to avoid reinstalling my iPAQ really.) :-) [1] http://buildd.emdebian.org/repos/tools/empath/trunk/ -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpwzpIZdrOkA.pgp
Description: PGP signature