Re: SLIND and chroots
On 2006-12-31 14:14 +0000, Neil Williams wrote:
> 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?
I'm not sure what was being referred-to there. I would have thought it
was erik andersen's build of debian woody with uclibc, but then it
would say uclibc, not glibc. Perhaps it is referring to slind or nokia
work?
I suspect I wrote that text, but I can't remember what the comment was
based on :-(
That whole page is probably due for an update anyway.
> How up to date is SLIND?
The one on the CD is Feb last year (fosdem) . The developers obviously
have newer stuff.
> 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 imagine you are right.
> 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?
We did work out an answer to this question at debconf 5, based on the
maemo mininmal set. There are two possible answers. The busybox-based
'base' and the 'debian-a-like' base. Ideally they would be
interchangeable, although tere will no doubt be ifs and buts about
that.
I'm sure I wrote a mail or wiki-page detailing this (eventually in
2005) but I can't find it. Fortunately zumbi is better-organised than
me and it is recored in his helsinki-report:
http://linuxupc.upc.es/~hecormar/emdebian-workshop-050711.txt
That list could no doubt be refined 18 months later, but it's a good
start.
> 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.
This would certainly be nice, and could provide as a side-effect a
relatively painless way of bootstrapping Debian, which is currently a
right PITA. In practice I think this would be implemented as a script
to example reprero transitions on the server - check all the
build-deps are satisfiable before installing it.
I don't know if there are tools that already help here. GYrosgeir
may have some relevant code?
> 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. :-(
Hmm, so it does. Looks like it need moving forward to libgnome2 as well.
Wookey
--
Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679
work: http://www.aleph1.co.uk/ play: http://wookware.org/
Reply to: