[pkg-fso-maint] FSO data files

[Luca Capello]

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