HOWTO: About running fsvs on older systems
[A small collection of HOW-TOs]

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.

Why do I need this?

You possibly want to use FSVS on some older system, but don't want to build everything needed there - apr, subversion, neon, ...

How it doesn't work

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.

How it does work

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 the old system

On your old system you use an additional parameter for configure:

 ./configure --with-chroot=/usr/local/fsvs-chroot
 make

This builds only tools/fsvs-chrooter -- this you put into /usr/local/bin or whereever you like. It should be in a directory listed in PATH!

What to do on the current (updated) machine

You take FSVS and copy that with all needed libraries into some new directory structure on your old system; eg. /usr/local/fsvs-chroot.

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 *.so.*, and locale-archive.

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.

Note:

You'll also see some additional files in the strace output - such things as /etc/hosts, /etc/resolv.conf, /etc/nsswitch.conf and so on. These tell the network libraries how to resolve names via DNS, and similar data.
They should normally be identical to the file on the target machine; to keep them the same, it might be a good idea to have them copied into the chroot jail from time to time.

A binding mount would be better still - but as /etc/ld.so.cache should be taken from the newer machine, you'd have to do every single file.

It should be possible to simply have no ld.so.cache file; then the dynamic linker would have to search the directories by himself.

How is this used, then?

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.

Prepare script

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.

Note:

Most of the libraries listed in the environment variable could be removed, as they're referenced in the fsvs binary. Only the few that are not automatically loaded have to be in the list.

Some thoughts and technical details

Note:

Why does FSVS-chrooter set two directory variables?
We need the old / to set the correct root directory back; and the current working directory has to be restored, too.
If we did a 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).

Maybe give the chrooter setuid and drop priviledges after returning from chroot() jail? Not sure about security implications, seems to be unsafe. Does anybody know how to do that in a safe manner?

If your old system is a really old system, with a kernel before 2.4.17 or something like that, you might get problems with the threading libraries - libpthread.so.
Search for LD_ASSUME_KERNEL to read a bit about the implications.

Information about how to proceed there is wanted.

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.