On 16/03/12 23:09, Marco Schulze wrote:
> 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?
>
/opt is not FHS.
/usr/bin is not FHS in the way that you're proposing. It should be used for us
debian-staging follows FHS to as much of an extent as possible, although there
was one minor issue possibly with its use of /var/run/freenet.
"Why shouldn't autoupdate work" - if you look through how the current updater
works, it's fairly self-evident why it won't work for the package built by
debian-staging.
> An unrelated question: it seems debian-staging not only builds slightly
> different jars, but are locked on specific build numbers. Why?
>
I haven't had time to update the submodule pointers to the latest commits and
verify that the package still works. Does this answer your question?
> 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
>
>
> _______________________________________________
> 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/20120319/da883b28/attachment.pgp>
