On Apr 14, 2010, at 12:31 PM, Karol wrote:
Hello,
I've been wondering for some time if it would be possible create
pbuilder-like infrastructure on top of scratchbox2 (for
building .debs).
Namely, what I would like to have is tools (consisting of say
squeeze +
cross toolchain) and target (say armel). I can setup these with
debootstrap, no problem here.
You didn't say if you intention is to compile squeeze for armel. I
hope it is, if your tools are based on that.
Our experiments with various configurations have *proved* that the
safest way is to use the same base system for tools as what you are
compiling. I.e. 100% same sources, just different binary architectures.
Well, the "devel" mode of sb2 was originally based on an idea that we
could use tools from debian (first from etch, later from lenny) to
compile something else (Maemo's sources). But it isn't really a good
idea; usually works, but it isn't a generic solution. Note that
scratchbox1 suffers from the same problems; devkits are usually not
too well in sync with the distro that you are compiling, and it causes
pain there, too.
One thing that causes much trouble is that there appears to be lots of
silent dependencies between the source packages and the tools. Many
OSS tools are not at all forward- or backward compatible with itself
=> my recommendation is that please try to use a consistent starting
point, and don't mix tools from another distribution with something
else. Unless you really have to (for bootstrapping an own distro, or
something like that?)
Latest versions of sb2 have also another development mode, "accel",
which can be used when your tools and target distributions are the
same. Use it if possible, it is simply better than what "devel" can
ever do.
However, problem starts with introduction of non-trivial Build-Depends
(other than 'build-essential'). Having basic native/target
environments
I would like to automatically resolve and install dependencies.
devel's mode dpkg-checkbuilddeps wrapper is quite capable of
handling pre-
setup environment, however I have hard time finding how to
automatically
decide which packages would be needed to be installed to tools,
target or
tools+target.
The solution is simple: You should install all missing dependencies to
the target ("rootstrap"). If that brings in some additional tools as
armel binaries, that only means that they will be slow. But still safe
to use.
There is no way to automatically decide what can be installed to
tools. And the reason for this is quite simple, too:
Some tools are not safe to be executed with a "wrong" cpu
architecture. Most are safe, but not all => the contents of "tools"
must be selected manually.
My investigation suggests that I would basically need to modify dpkg-
checkbuilddeps (because intelligence is already there) and:
(1) download given missing package for an architecture (say - tools'
amd64), hmm... maybe use apt-file instead of downloading package in
this
step
(2) check what files are included in package (and/or use include/
exclude
lists) and decide if this package is installable on tools, target or
both
(3) install package(s) where it belongs
(4) repeat this for every package in build-depends.
I have used a simpler approach:
1. extract the sources
2. run dpkg-checkbuilddeps ("accel" mode) and if nothing was missing,
just go and build it.
3. if dependencies were missing, set up a temporary environment: let
sb2 clone the rootstrap to a ramdisk, install dependencies ("emulate"
mode), and build using this temporary rootstrap ("accel" mode).
Repeat that for each package.
(if you are familiar with sb1, you'll probably notice some
differences: First, with sb2 you don't have to extract the target file
system each time, as it is R/O in this case, and second, it is really
easy to speed up the build by using a ramdisk with sb2)
Also, you probably don't need to modify the dpkg-checkbuilddeps
wrapper. Some people have just parsed output of it, and used a
separate tool to get the dependencies.
However... I guess even that wouldn't be sufficient as I would need to
solve dependencies manually. That looks like a mess for me. Huge
mess.
Maybe I'm missing something? Something obvious? Hints, suggestions,
tools-from-under-the-carpet - more than welcome. ;)
If you have a private repository for your .deb packages, then you
don't have to manually solve any dependencies. Just use "apt-get build-
dep".
I might have something that could be useful, as examples about how sb2
can be used: The scripts that I have used for building massive amounts
of packages. Unfortunately those are currently in that kind of state
that they should stay under the carpet ;-) ...but if you are
interested, I can try find some time to clean up those.
Lauri
_______________________________________________
Scratchbox-devel mailing list
[email protected]
http://lists.scratchbox.org/cgi-bin/mailman/listinfo/scratchbox-devel
