[pkg-fso-maint] FSO data files
Luca Capello
luca at pca.it
Mon Oct 6 20:04:37 UTC 2008
Hi Joachim!
On Mon, 06 Oct 2008 18:17:46 +0200, Joachim Breitner wrote:
> Am Montag, den 06.10.2008, 00:35 +0200 schrieb Luca Capello:
>> * fso-framworkd-scenarios
>> the scenario files now in /usr/share/openmoko/scenarios
>
> Also good.
This should be fso-frameworkd-scenarios-gta02, read below ;-)
>> * fso-frameworkd-data
>> all the rest (/etc/frameworkd.conf, /etc/pointercal and udev rules)
>
> /etc/frameworkd.d should go into fso-frameworkd, as it’s the
> configuration for that package.
This is not completely correct: the frameworkd.conf we ship is a
configuration file for frameworkd *on* the GTA02, while the general
(i.e. no hardware-specific) configuration file is provided as an example
(conf/examples/frameworkd.conf) but we don't ship it in the Debian
package. FWIW, with this general configuration file frameworkd starts
and I can make a call.
I see two solutions:
- we provide the general one, which means that we need a way to modify
it for the GTA02 (or GTA01 or $WHATEVER), AFAIK not so simply (since
frameworkd doesn't support something like /etc/frameworkd.d/)
- we don't provide anything at all, but the general one in the
doc/examples directory. We add a note into README.Debian and we patch
fso-frameworkd.init to check for a config file before starting, so
frameworkd doesn't even start:
--8<---------------cut here---------------start------------->8---
--- a/debian/fso-frameworkd.init
+++ b/debian/fso-frameworkd.init
@@ -30,6 +30,10 @@ PIDFILE=${PIDDIR}/${NAME}.pid
case "$1" in
start)
+ if [ ! -r /etc/frameworkd.conf ]; then
+ echo "No readable /etc/frameworkd.conf found, exiting."
+ exit 1
+ fi
[ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
start-stop-daemon --start --pidfile ${PIDFILE} --make-pidfile --background --exec ${DAEMON}
[ "$VERBOSE" != no ] && log_end_msg $?
--8<---------------cut here---------------end--------------->8---
I strongly prefer the latter, because it lets frameworkd as
hardware-agnostic as possible.
A further step with the latter solution would be to have fso-frameworkd
depending on fso-frameworkd-conf, a virtual package provided by
fso-frameworkd-conf-generic (the example configuration, source
fso-frameworkd), fso-config-gta02 (source openmoko-files, read
below), etc. But I'm not sure this would bring anything more than extra
work for us...
> The other two are hardware-related, and not frameworkd related. Maybe
>
> fso-etc-gta02
> or
> fso-config-gta02
> or
> fso-hardware-gta02
My vote goes for fso-config-gta02.
>> Obviously, fso-frameworkd will depends on all the three packages.
>
> I wouldn’t depend on the hardware related parts, so people can try
> fso-frameworkd on their desktop machine or similar.
Fully agree, thus Recommends: :-)
> I also don’t think that they should be all in one source package, but
> rather each have their own. It would be nice to be able to upgrad
> fso-frameworkd without downloading the new, but unchanged, -sounds
> package.
Ops, sorry, I think I wasn't clear, let me (try to) explain...
- fso-frameworkd contains only frameworkd strictly necessary files, thus
no configuration, no sounds, no scenarios
- configuration files from upstream (frameworkd.conf, pointercal and
udev rules) goes into one single source package (openmoko-files),
which generates ATM two binary packages (fso-config-gta01 and
fso-config-gta02).
These files are necessary for a working frameworkd as well as X11.
- sound files get their own source packages:
+ fso-sounds-nonfree for Asterisk.sid and notify_message.mp3 [1], with
binary fso-frameworkd-sounds-nonfree
+ fso-sounds-yue (since they're given specifically for the FSO
project [2]), with binary fso-frameworkd-sounds-yue
I'd not include any sound in the configuration-file package for two
reasons:
a) you don't need the sounds to use the phone, only to receive
notifications (which are useful, not strictly necessary)
b) as soon as we put Asterisk.sid somewhere, the source package
belongs to nonfree
- scenario files can either have their own source package or be included
into the configuration-file source package. My vote goes to the
latter, because these files should not change so often and we've all
the necessary files in one package. Moreover, AFAIK we've scenario
files for the GTA01 and different ones for the GTA02. Anyway, the
binary package should be called fso-frameworkd-scenarios-gta02, etc.
Again, the scenario files are not stricly necessary: frameworkd starts
nicely without them.
I'm now pondering if we should not change the sound and scenario package
names into something more general, like fso-sounds-nonfree and
fso-scenarios-gta02: while these files are used by frameworkd, they
aren't specific to it.
Thx, bye,
Gismo / Luca
Footnotes:
[1] we still need to sort out the licenes for it...
[2] http://www.yue.it/en/music.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 314 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-fso-maint/attachments/20081006/73f28a2b/attachment.pgp
More information about the pkg-fso-maint
mailing list