Well, the obvious question is 'why?'. Using /opt + /usr/bin scripts +
service scripts seems to be good enough. Either way, fred .jar paths are
configurable, the jars themselves should have 6** permissions and be
owned by the fred user. Why shouldn't autoupdate work?
An unrelated question: it seems debian-staging not only builds slightly
different jars, but are locked on specific build numbers. Why?
On 16-03-2012 17:51, Ximin Luo wrote:
We already have a layout that adheres to the FHS, see debian-staging for
details :)
But this is only for run-time data, NOT the binaries themselves. That part is
rigid and would require much more work, because (to implement it properly)
would need to integrate well with all the various existing installers, as well
as the built-in updater.
I'll respond to the other points some other time, need to be off somewhere now.
(Theoretically it would be possible for fproxy to expose an APT repo under e.g.
localhost:8888/debian/ that actually gets its data from freenet, but this is
again extra work.)
X
On 16/03/12 20:38, Marco Schulze wrote:
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).
_______________________________________________
Devl mailing list
[email protected]
http://freenetproject.org/cgi-bin/mailman/listinfo/devl
_______________________________________________
Devl mailing list
[email protected]
http://freenetproject.org/cgi-bin/mailman/listinfo/devl
_______________________________________________
Devl mailing list
[email protected]
http://freenetproject.org/cgi-bin/mailman/listinfo/devl
