On 18-03-2012 22:11, Ximin Luo wrote:
> On 19/03/12 01:09, Ximin Luo wrote:
>> 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.
I guess using /opt is not strict FHS, but it's commonly used for
packages that, for some reason, can't be spread out in the filesystem.
>> /usr/bin is not FHS in the way that you're proposing. It should be used for
>> us
>>
> Forgot to finish this sentence. I meant to say, /usr/bin is used for user-run
> programs only. Maintenance scripts go in /usr/lib/freenet or
> /usr/share/freenet, and the daemon script should be /etc/init.d/freenet.
True.
>> 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.
The question was more general: why shouldn't autoupdate work using an
FHS layout?
>>
>>> 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
>>
>>
>>
>> _______________________________________________
>> Devl mailing list
>> Devl at freenetproject.org
>> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>
>
>
> _______________________________________________
> Devl mailing list
> Devl at freenetproject.org
> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20120319/ea15d6b6/attachment.html>
