On Apr 5, 2010, at 7:17 PM, ext Michael Turney wrote:
Folks,
I spent a good deal of time in February/March trying to get sb2
working correctly
to support an ARM cross environment. Since the list was offline
during that time,
I had to experiment in a vacuum. End result is I gave up. Now that
the list is back
online, I would like to understand a few items that caused a lot of
grief.
The big hurdle was getting sb2 -eR to work correctly with my target
filesystem.
I always got a permission issue. I went back and realized I missed
a step,
which was the target filesytem had to be owned by me under my $HOME
directory.
When I stopped using sudo to copy the filesystem, a number of things
happen,
a) .../dev nodes don't get populated (which isn't a problem)
b) a number of other files wouldn't copy (again, not a problem)
c) my $USER owns the new tree under my $HOME
d) sb2 -eR now works fine
So, what's the problem? The new filesystem is basically useless to
me to run
on the target. After doing my cross package builds I copy the new
tree back
to the boot device for the target (in this case a USB thumb-drive)
and the target
no longer boots correctly.
After much trial/error, I learned that I could just copy back the /
usr/local tree from
my $HOME tree to the target boot device and the target would boot.
Copying the
whole / tree was a disaster, as was copying the whole /usr tree.
So, full circle back to subject line, is this working as designed or
am I missing
something really important? Can sb2 be used to build and populate a
generic
package anywhere in the filesystem or am I limited to the /usr/local
tree?
We have used the "emulate" mode ("sb2 -eR") to install packages to the
target file system successfully from the very early days of
development. There are some very small limitations (e.g. you can't
write to /etc/resolv.conf in the "emulate" mode), but in general, it
is possible to install the packages to various locations. Not just to /
usr/local.
However, note that since sb2 has been designed to operate completely
as an user-level solution, there will be problems if you try to copy
the FS back to the device. Content of the files should be 100%
correct, but the metadata will be lost; owners and permissions will be
incorrect. Probably this was reason why your experiment failed.
Currently sb2 relies on "fakeroot" when you need to have simulated
root rights (that is what you get with the "-R" option), so same
restrictions apply as what you get from "raw" fakeroot: Even if the
permissions etc. appear to be OK inside the sb2 + fakeroot sessions,
the metadata will be lost when the fakeroot session ends.
It should be possible to save and restore fakeroot's fake metadata db
(see options -s and -i of fakeroot), but we haven't tried that, so sb2
does not currently support it. Mostly because we haven't needed such
feature; we don't copy complete filesystems back to the device. It
should not be too difficult to add, so I'd be happy to integrate it if
someone wants to implement it.
After I got sb2 -eR working I experimented with pulling and building
a generic
OSS package (started with hello-debhelper), and there were issues/
problems
with building a debian package. Same tree would configure/build/
install correctly,
just not run the debianization step correctly (dpkg-buildpackage).
I'm not asking for help to solve a specific issue (I no longer have
the error
messages, anyway).
I am curious if sb2 should be able to run dpkg-buildpackage and how
a target
filesystem manipulated with 'sb2 -eR' can be copied back and allow a
target
to boot correctly. I am assuming my issues with the latter were
related to
ownership.
Yes, dpkg-buildpackage works, too. But did you try to use the
"emulate" mode for that too?
"emulate" is intended for device emulation, while there are separate
mapping modes for cross-building: "simple", "devel" and "accel".
"simple" is enough for some basic things, while the latter ones have
been designed to be support also more demanding packages (e.g. you
can't build perl extensions in the "simple" mode safely, etc)
Lauri
_______________________________________________
Scratchbox-devel mailing list
[email protected]
http://lists.scratchbox.org/cgi-bin/mailman/listinfo/scratchbox-devel
