K.-P. Kirchd�rfer wrote: > The long term idea by Arne or Martin has been to chroot into staging > and run our own distro from there. > I've asked myself, but then with all the problems with some packages > leaking on some machines, I understood it may help in the long run.
I happen to disagree on this one, but I'll follow their lead...
I think that it's more important to keep staging dir clean, and if you want to test-run a distro (assuming you have the same CPU), you could/should just have a small script that untar's all the LRPs into a chroot jail. That way you also test to make sure the .lrp's were packaged correctly (you remembered to include all the files the router needs).
I feel that the staging directory really should be reserved for the toolchain and supporting libraries (i.e. include files and shared libraries) required by other packages.
I've been building both debugging and non-debugging versions of upnpd, and I live in fear that I didn't sanitize staging_dir and clean out the old libraries. It's much easier to just rm -rf target_dir/upnpd and not worry. It also means I can have separate versions of upnpd in the tree and not have them install crap over each other.
Minor point, but just wanted to share my two cents. I'll follow the current consensus of the group.
Paul
p.s. has anyone tested how "clean" our build environment really is?
I've got some worries about include file and library file cross-polination from the host build environment...but I haven't dug into the gcc spec file for the cross compiler to make sure it never includes anything from /usr/include and LD never looks at /usr/lib.
can buildtool run under freebsd to produce a LEAF binary?
can buildtool run on a powerpc to produce an i386 binary?
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
_______________________________________________ leaf-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/leaf-devel
