I hadn't been aware of the extent of the issue with relative paths but had thought there might be something like that present. Because of it, I had been using /usr/lib/synchronet as the install directory for exec/* and then manually using a symlink to a runtime directory in /svr along with symlinks or sub-directories for the rest of the SBBS files and directories. It looks like it may be better, at this time in the development work, to use the /opt/synchronet file layout instead.
* Change to using /opt/synchronet as the main directory. (r94)
* Change to using /opt/synchronet/exec as the main executables directory. (r98)
* Add lintian override for installing files to /opt. (r99)
This is what deuce posted in in a message to me on 4/16/08 in SYNCPROG:
>> Synchronet is better suited to a /opt install if that is an option (should
>> be, it's part of the LSB hierarchy)
> On this note, the package would still need some patches to fit the LSB FHS 2.3...
> Basically, the data dir would need to be set to /var/opt/synchronet and the
> ctrl directory would need to be set to /etc/opt/synchronet.
> IIRC, many many things will break when you do this. A huge number of things
> use relative paths as I recall and those paths are almost always relative to
> ctrl. A fairly major scrub to replace those would be required.
> But wait!
> "If a configuration file must reside in a different location in order for the
> package or system to function properly, it may be placed in a location other
> than /etc/opt/."
> So, you can keep ctrl and make /opt/synchronet/data a symlink to var/opt/synchronet. > This should work fine.
> So the dir tree at the end looks somethng like this:
> /opt/synchronet/data -> /var/opt/synchronet/data
> /opt/synchronet/node1 -> /var/opt/synchronet/node1
> /opt/synchronet/node2 -> /var/opt/synchronet/node2
> /opt/synchronet/node3 -> /var/opt/synchronet/node3
> /opt/synchronet/node4 -> /var/opt/synchronet/node4