[Scratchbox-users] Problems with tools in debian devkit. Can some/all tools be replaced?

[Jim Heck]

I'm trying to build a set of packages using Crocodile beyond the 
build-essential set, to encompass enough packages to run debootstrap 
fully using only packages I have built in a reprepro repository.  Many 
packages build, but a bunch are giving me grief. 

Two questions, one specific and then one general.

Specific question.
One example of a package I'm having problems with is console-data.

The first problem I had with this package was that the 'psfaddtable' 
tool has changed how it takes arguments and the latest source package in 
Sarge makes use in the rules file of the tool's new argument structure.  
This was a relatively minor issue (a cat of the patch is at the end of 
this message), where a '-' that used to be required as a file 
placeholder is no longer needed (and no longer supplied in the rules 
makefile).

A more serious problem occured after I fixed this, involving how 
pbuilder-satisfydepends works to resolve and install build dependency 
packages.  The problem surrounds the 'dh_consoledata' tool, which is in 
the dh-consoledata package, built as part of the console-common source 
package, and related to debhelper.  Scratchbox provides a version of 
this tool.  The package dependency check passes, but the console-data 
build chokes when it can't find a required file to run the 
'dh_consoledata' tool as follows:

dh_consoledata -i
/scratchbox/tools/bin/sh: line 1: 
/usr/share/debhelper/dh-consoledata/config.in: No such file or directory
dh_consoledata: command returned error code
make: *** [binary-indep] Error 1

The file /usr/share/debhelper/dh-consoledata/config.in truly does not 
exist.  Now I had already sucessfully built the console-common source 
package, so the dh-consoledata.deb file is sitting in my 
crocodile/work/built/ directory, and could be installed.  This package 
contains what I assume is an alternate working version of the 
dh_consoledata tool, including the needed files for dh_consoledata to 
work.  Unfortunately, pbuilder-satisfydepends decided not to install 
that package, and use the Scratchbox provided version instead (which is 
missing the needed file).

 -> Attempting to parse the build-deps : pbuilder-satisfydepends,v 1.18 
2003/04/20 03:40:36 dancer Exp $
 -> Considering  dbs
       -> Using unversionedly scratchbox for: dbs
   -> Trying dbs
       -> Using scratchbox for: dbs
 -> Considering  debhelper (>= 4.1.6)
      Using scratchbox provide: debhelper 4.2.32x
   -> Trying debhelper
       -> Using scratchbox for: debhelper
 -> Considering  dh-consoledata
       -> Using unversionedly scratchbox for: dh-consoledata
   -> Trying dh-consoledata
       -> Using scratchbox for: dh-consoledata
 -> Considering  sharutils
   -> Trying sharutils
 -> Considering  console-tools
       -> Using unversionedly scratchbox for: console-tools
   -> Trying console-tools
       -> Using scratchbox for: console-tools
 -> Installing  sharutils
Reading Package Lists...
Building Dependency Tree...
sharutils is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
 -> Finished parsing the build-deps

So, in a crocodile build scenario, is it possible to have 
pbuilder-satisfydepends defer to installing the package if it is built 
instead of using the Scratchbox version?  Would this even work (I can 
imagine installing the second version in addition to the Scratchbox one 
could cause problems)?  I'm running into several problems more like the 
first where the tool has changed and the modern Sarge makefiles employ 
the wrong syntax.

Now for the more general question.  Is there a general way people use to 
build all the tools they need from sources, bypassing the use of 
many/any Scratchbox versions of the build tools.  I'm not interested in 
speed, only correct execution, so I don't mind if the tools need to run 
under QEMU, so long as they run correctly.  There is sort of a chicken 
and egg problem here, in that it seems you need the Debian devkit in 
order to build any packages in the first place, but would it be possible 
to then create a Scratchbox sandbox that does not include the Debian 
devkit, and instead uses the Crocodile set of packages to provide all 
the build essential tools?  In other words, once build-essential is 
done, create another sandbox without the Debian devkit but with access 
to the Crocodile packages and build additional packages here.  The 
documentation seems to indicate that the Debian devkit also sets some 
environment variables in addition to populating tools.  Really what I am 
looking for is to have built as much from Sarge source as possible, so 
I'm depending as little as possible on specific versions of tools from 
the devkit.

I've read a bit about Scratchbox 2, and it sounds somewhat more like 
what I'm trying to do here, but I haven't found enough to really 
understand if it is ready to be fully used, and if so, what the ins and 
outs are vs the older Scratchbox.

Any help as always appreciated.

Thanks,

-Jim Heck

Example cat of patch file to fix a tool problem with console-data:


diff -Naur console-data-2002.12.04dbs/debian/rules 
console-data-2002.12.04dbs-patched/debian/rules
--- console-data-2002.12.04dbs/debian/rules     2004-11-13 
11:51:10.000000000 -0500
+++ console-data-2002.12.04dbs-patched/debian/rules     2007-01-05 
09:50:44.000000000 -0500
@@ -83,7 +83,7 @@
        mkdir -p  ${installdir}/usr/share/consolefonts
        # First fix the sfm tables in the lat2u fonts
        for d in ${topdir}/build-tree/extras/consolefonts/lat2u-*.psf ; do \
-               psfaddtable $$d 
${topdir}/build-tree/${TAR_DIR}/consoletrans/lat2u.sfm > X ; \
+               psfaddtable $$d 
${topdir}/build-tree/${TAR_DIR}/consoletrans/lat2u.sfm - > X ; \
                mv X $$d ;  \
        done
        #