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
> Devl at freenetproject.org
> http://freenetproject.org/cgi-bin/mailman/listinfo/devl
--
GPG: 4096R/5FBBDBCE
https://github.com/infinity0
https://bitbucket.org/infinity0
https://launchpad.net/~infinity0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20120316/43af71d9/attachment.pgp>
