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

[Jim Heck]

Riku Voipio wrote:
> -snip-
>
> You are attempting to work around a issue: dh-consoledata is
> broken in debian devkit. Either you can fix console-data build rule,
> or you can just remove /scratchbox/devkits/debian/deb_list/console-common.
>
> In general current system should match sarge, and if it doesn't it's 
> a bug.
>
>   
I tried to remove /scratchbox/devkits/debian/deb_list/console-common, 
but this just leads to a cascade of problems.  Then, the package 
dh-consoledata is not installable, since it has a dependency on 
debhelper, which is not installed from the viewpoint of apt-get (since 
it is also provided by the debian devkit and apt has no record of it as 
installed).  The debhelper package in turn should I try to replace it 
would be dependent on several more packages (such as dpkg-dev, cpio, 
etc, which in turn have install dependencies on nasty things like 
binutils).  Essentially it looks like all of the stuff the debian devkit 
provides would need to be built and made to replace those pieces to 
satisfy the cascade of dependencies (if that is even possible), since 
all the stuff in the devkit is unknown to apt-get, and therefore cannot 
satisfy install dependencies of packages being installed.  Is there a 
way around this?

This leaves me with three choices and I'd like to get a read on where 
best to place my efforts.

1. Try to fix the debian devkit.  Is this actively being supported at 
this point for such fixes?  How hard could I expect this to be?

2. Try to work around the problem.  I was confused by your suggestion to 
fix the console-data build rule, do you think I can avoid using 
dh-consoledata and still build the console-data package (or what I would 
commonly need of it)?

3. Pour my efforts into scratchbox2.  From the link you provided, it 
looks like SB2 development is coming along pretty well, but as you 
pointed out is not yet ready to build Debian packages or install target 
libraries.  From the lack of a chroot environment in SB2, this effort 
looks a lot more like the emdebian approach (http://www.emdebian.org/)  
Is that a fair assesment, or am I missing something obvious on how SB2 
is meant to work?

Thanks,

-Jim Heck
> This is exactly something that scratchbox2 [1] should make possible.
> Or actually better, you don't need to _avoid_ host tools in order
> to select your preferred host tools versions. You can just install
> the version you want. Currently sbox2 can build applications 
> (./configure ; make ; make install) , however nobody has written
> enough remapping rules to build .deb:s (should be easy) or install
> target libraries with apt-get (a more tricky problem). I suggest you
> take a closer look, sbox2 is much smaller and easier to grasp than
> 1.x series. The only hard part is the remapping engine.
>
> [1] http://rahina.org/sb2/
> _______________________________________________
> Scratchbox-users mailing list
> Scratchbox-users at lists.scratchbox.org
> http://lists.scratchbox.org/cgi-bin/mailman/listinfo/scratchbox-users
>
>