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
#
_______________________________________________
Scratchbox-users mailing list
Scratchbox-users@lists.scratchbox.org
http://lists.scratchbox.org/cgi-bin/mailman/listinfo/scratchbox-users
