This document explains how the chroot-wrapper for FSVS works, and how it has to be configured. More...
This document explains how the chroot-wrapper for FSVS works, and how it has to be configured.
You possibly want to use FSVS on some older system, but don't want to build everything needed there - apr, subversion, neon, ...
An easy workaround would be using a chroot-environment - but then you don't have access to the data you'd like versioned.
Another way is to use
LD_LIBRARY_PATH - but that doesn't work (at least for me) for the later-loaded libraries, like
libnss_dns and so on.
Even using the
rpath parameter for linking doesn't quite work - all dynamically loaded things, like locale data, timezones, message tables, and so on are taken from the current root on - and may not match the needed versions.
A small helper program allows to copy FSVS (with needed libraries) from a current system (like debian unstable) to any (architecturally matching) other distribution, without worrying about library incompatibilities.
This works by calling this wrapper program; it goes into a
chroot jail and calls FSVS with additional data; FSVS then tries to load all needed libraries (see hlp__chrooter), and goes out of the jail to resume operations from the default enviroment.
On your old system you use an additional parameter for
./configure --with-chroot=/usr/local/fsvs-chroot make
This builds only
tools/fsvs-chrooter -- this you put into
whereever you like. It should be in a directory listed in
You take FSVS and copy that with all needed libraries into some new directory structure on your old system; eg.
Don't forget to copy the later-loaded libraries and data files -
ldd fsvs won't give you the whole list! You can get a good list to start (on the current machine) with
strace -e open -o /tmp/list fsvs remote-status
as that opens a repository connection. Not everything from this list is needed; generally only files matching
Please create the whole structure (as far as needed) as it is - ie.
/usr/local/fsvs-chroot/ lib/ libc.so.6 ld-linux.so.2 ... usr/ lib/ libnss_dns.so ... local/ bin/ fsvs
Why? First, it's easier for you to update later, and second the dynamic linker knows where to look.
straceoutput - such things as
/etc/nsswitch.conf and so on. These tell the network libraries how to resolve names via DNS, and similar data.
/etc/ld.so.cache should be taken from the newer machine, you'd have to do every single file.
ld.so.cachefile; then the dynamic linker would have to search the directories by himself.
FSVS-chrooter can be called just like fsvs - it relays all parameters into the jailed binary.
Although it might be better to set the environment variables for
fsvs-chrooter in a shell script named FSVS - then the other programs won't have to put up with the long library list.
The prepare script below generates such a file.
If you look into
tools/, you'll find a script named
prepare-chroot.pl. This is what I use to create the
chroot jail on my debian unstable machine.
/to set the correct root directory back; and the current working directory has to be restored, too.
chroot(current working directory), we'd see a completly different directory structure than all the other filesystem tools (except for the case
cwd = "/", of course).
LD_ASSUME_KERNELto read a bit about the implications.
If this doesn't work for you, because some function which would load additional datafiles isn't called, try the
strace trick. Patches are welcome!
Ideas, suggestions, feedback please to the mailing lists.