Re: chroot building

[Jim Heck <jsurf@heckheck.com>]

Neil Williams wrote:
> There's an outline of a pbuilder create wrapper in SVN
> (tools/em_make/empdebuild) - once a few more packages are built, we
> should have a usable chroot environment using the emdebian target
> repository.
>
>   
Wow, I'm really impressed with how far and fast Emdebian seems to be 
coming along.
> My questions are:
>
> If I make the basetgz use arch=arm, the chroot will not be
> cross-building anymore. This native chroot would only use the emdebian
> target repository. The native chroot can check the integrity of the
> archive (a la piuparts) by trying to install binaries from the emdebian
> target repository but is this native chroot useful for anything else?
> Is there any point making the native chroot able to rebuild cross-built
> packages? (It could make the emdebian target repository quite messy).
> Is it possible to run GUI (or any) programs from within such a chroot?
>
> Alternatively, drop arch= (and --foreign) from the debootstrap options
> and use two mirrors: the emdebian toolchain and the emdebian target
> repositories. I'd use this for building GUI packages because it means I
> don't have to install dozens of dependencies via dpkg-cross on my main
> system, instead the chroot runs dpkg-cross (via apt-cross) and then
> emdebian-tools.
Personally, I think this is a good approach, more on my rationale below.
>  This is more complex because it means adding a normal
> Debian mirror to the chroot sources.list so that the correct build
> dependencies are available (like dpkg-cross, debhelper, perl and
> emdebian-tools). That makes it harder to spot missing packages.
> Essentially, this would be a normal pbuilder environment with emdebian
> packages taking priority.
>
> Do we want to support both? I'm beginning to think we should.
>
> I could enable support that packages are built in the cross chroot,
> and then tested in the native chroot prior to upload. That would mean
> that any missing packages arising from the cross chroot method will be
> caught at that stage. If packages are uploaded without being tested in
> the native chroot or if they fail to install in the native chroot at a
> later date, we could use a release-critical FTIN {fails to install
> native} bug once we have an operational BTS.
>
> What do we need for a buildd? native or cross?
>
> One idea for the cross-chroot is that dpkg-cross packages could be held
> in a third repository at emdebian.org or added to the toolchain
> repository. That would preclude the need for a Debian mirror and make
> it easy to spot missing packages. The problem there is that dpkg-cross
> doesn't make it simple to generate a .changes file so the dput upload
> needs to be adjusted. Also, has anyone tried 'dpkg-cross -A' on perl?
>
>   
I like the idea of a third repository, since I think it makes it easier 
to keep track of exactly what constitutes a complete and proper set of 
packages needed to build some specific subset of Debian packages.  I 
guess apt-cross could do this anyway without the chroot, but it gets a 
bit trickier to sort out exactly whether a dependency was "incidentally" 
met based on some stray package you had installed on your system.  Also 
as a side effect, it would be useful for people interested in leveraging 
Emdebian using their own local set of repositories for source and 
libraries.  In other words, if I'm interested in a simple subset of 
Debian and want to build it all from scratch outside of the "standard" 
Debian unstable, testing and stable branches, I think the cross chroot 
will help identify exactly what set of packages are necessary.  Of 
course this is tangential to the overall Emdebian effort to always be in 
sync with Debian, but for some it might be quite a convenience.    
>   
> If the native chroot works out, that may be the best method. Much like
> Debian, it means that building a package can involve two builds: one on
> the host system (debuild) and one in a chroot (pdebuild). Emdebian
> could use emdebuild for "base" packages and empdebuild --cross where
> there are lots of dependencies, followed by empdebuild --native which
> would be a similar function to pdebuild - checking all necessary
> dependencies are available. In our case, empdebuild --native checks
> *runtime* dependencies rather than build-depends. (Or should empdebuild
> always be --cross and a new script, emparts or eminstall for testing
> the runtime dependencies?)
>   
> Remaining packages include util-linux, busybox and apt. I'll use the
> SVN versions to view the changes necessary but the current upstream
> sources, along with emdebian-tools, to actually create the new packages.
>
> There are a few issues with the emdebian website package search scripts
> at the moment, some packages are not showing up. xorg / x11-common are
> there, amongst others. Hopefully that won't take too long to fix.
>
> --
>
>
> Neil Williams
> =============
> http://www.data-freedom.org/
> http://www.nosoftwarepatents.com/
> http://www.linux.codehelp.co.uk/
>
>