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).