On 16-03-2012 15:13, Matthew Toseland wrote:
> Updating its own binaries is incompatible with the standard unix way
> of doing things, isn't it? Even if it's not technically a violation of
> FHS?
I'd just like to point out that this is not the case at all, specially
because flexibility is a major characteristic in this Unix Way of Doing
Stuff. Where it might be problematic, if at all, is on the package
management level:
- The ugly custom installer would have to be replaced by a
distribution-specific package;
- Some distributions have special rules regarding Java packages. You'd
have to check those;
You _can_ conform to the FHS without any change by being installed under
/opt. This will make fred accessible system-wide, so you might want to
check if it's ok to let multiple users delve inside the Freenet
directory tree. However, AFAIR, install scripts can do almost anything,
including creating a fred-specific user and group, and allowing
freenet{,-ext}.jar to be updated by that user without root privileges.
The new directory layout might look like this:
/etc: freenet.ini.
/usr/bin: shell scripts to launch and update freenet.
/usr/lib: native libraries.
/usr/lib/fred: jars. This might be dependent on the distribution.
/srv/fred: default download location (if system-wide daemon, ~/Downloads
otherwise).
/var/cache/fred: datastore and other miscellaneous persistent files.
/var/cache/fred/plugins: plugins directory trees.
/var/log: logs.
/var/log/old/fred: compressed old logs (do you really need those?).
Plus, distribution specific scripts to control the daemon (run.sh-ish).
