[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

SLIND and chroots


"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

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

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

Attachment: pgpwzpIZdrOkA.pgp
Description: PGP signature

Reply to: