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
>> Devl at freenetproject.org
>> http://freenetproject.org/cgi-bin/mailman/listinfo/devl
>
>
>
> _______________________________________________
> Devl mailing list
> Devl at freenetproject.org
> http://freenetproject.org/cgi-bin/mailman/listinfo/devl
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20120316/c56000b6/attachment.html>
