[pkg-fso-maint] [Debian] Device-agnostic fso-frameworkd: ready to go!

[Luca Capello]

Hi Joachim!

On Thu, 30 Oct 2008 14:38:59 +0100, Joachim Breitner wrote:
> Am Donnerstag, den 30.10.2008, 01:01 +0100 schrieb Luca Capello:
>> Now, the real problems :-(
>> 
>> 1) there's no easy way to install the device-agnostic fso-frameworkd
>>    package, since we opted to avoid unnecessary dependencies [9] (this
>>    is useful for people who wants to install fso-frameworkd on their
>>    desktop systems).
>
> Maybe a bit late, but did we consider providing a fso-config-nonphone
> (or -desktop, or -debug) package with all hardware stuff disabled? If
> so, fso-frameworkd could depend on the virtual package, and we can still
> install it on the desktop.

I have never considered that and I should say that this is a simple and
feasible option.  However, while I like it, it rises some concerns:

1) which fso-config-* package should be the default?  IIRC merely
   depending on the virtual package means that at installation time
   apt-get/aptitude/$WHATEVER chooses the first random package that
   provides the virtual one.  IMHO this is even worse than the current
   situation :-(

2) what should be put into that package?  The generic frameworkd.conf
   file?  In this case the package would be useless, since the end-user
   can easily do:

     # apt-get update && apt-get upgrade
       [read that /etc/frameworkd.conf is missing and required]
     # view /usr/share/doc/fso-frameowkrd/README.Debian
     # cp /usr/share/doc/fso-frameworkd/examples/fso-frameworkd.conf \
          /etc/frameworkd.conf
     # invoke-rc.d fso-frameworkd start

   I see frameworkd as a very specific software for a very specific
   purpose, i.e. managing a phone which can be a PDA, too.  In this
   respect, not all the users are capable of installing (and using) it
   on a desktop.

The current situation is already a bit too complicated: while
fso-frameworkd has no dependency on fso-config or fso-sounds, however
fso-config-* packages must depend on fso-sounds, since as soon as
frameworkd starts the default.yaml file [a] defines the ring- and
message-tones.  Thus, people can "just" install the correct fso-config-*
package and everything needed is automatically pulled in.

> The user upgrading on the freerunner should then hopefully notice that
> this package is not what he wants, and install the right one.

I fear that the end-user will start complaining about non-working
upgrades.  And yes, I think by experience I know quite well that
documentation is good, but not a lot of end-users read it.

The current situation *obliges* the end-user to acknowledge what he
does, which is exactly what I would expect when installing something
like Debian on the FR (and yes, I do not think Debian on the FR is for
everyone ATM).

> In the long term, maybe frameworkd could be equipped by upstream with
> hardware detection (or at least “device detection”), so that the config
> becomes hard-ware independent again – or even obsolete by default,
> similar to where the X server is heading.

I would be very glad when this moment will arrive (and I am sure it
will), however I do not see it for the forthcoming weeks, let us even
say months.

>> 3) upstream configuration system based on YAML is ATM less than optimal
>>    for how Debian ships configuration files: after having read [11], it
>>    seems the best option would be to configure fso-frameworkd at
>>    postinst, which is IMHO per se overkilling and prone to errors.
>>    Instead, I'd go on with the situation as it is and the end-user
>>    should check the differences every time she/he upgrades to a new
>>    fso-frameworkd version.
>
> Yes, no problem. Those who did not touch their config will be fine, and
> the others know what to do.
>
>> 4) while the update-alternatives solution for the fso-sounds-* packages
>>    is clean [12], however I'm not sure it takes care of local
>>    modifications.  We should provide instructions to create a local
>>    alternative with the highest priority, thus any upgrade doesn't
>>    change the default.yaml link.  However, point 6) above is vital for
>>    the ring- and message-tones configuration, too...
>
> What point 6?

Ehm, better point 3, which is still valid because of my concerns at [b].

>> I'd like to upload the new fso-frameworkd package as soon as possible
>> (at most this week-end), because I want to move on adding Ogg support
>> and then fixing every pkg-fso packages to upload to main.
>
> Note that milestone4 is expected this or the next week, so don’t worry
> too much about backporting.

Frankly speaking, there are still 23 active tickets [c]: 10 in ogsmd, 1
blocker, 2 criticals [d] and various majors.  I need anyway to wait for
the Yue sounds [e][f], but as soon as these sounds are available, I will
backport the Ogg support.

Even if the device-agnostics fso-frameworkd will ship only DFSG-free
files, it will require something not yet in Debian [g] until we have
found DFSG-free sounds and packaged them for fso-frameworkd.

If someone knows of some DFSG-free mp3 and wants to package them, she/he
feels to do it.  I support Free Softare and thus in this case my first
option is Ogg sounds.  I think, mostly I hope, you understand my
feelings.

Thx, bye,
Gismo / Luca

Footnotes: 
[a] /etc/freesmartphone/opreferences/conf/phone/default.yaml
[b] http://lists.linuxtogo.org/pipermail/smartphones-standards/2008-October/000646.html
[c] http://trac.freesmartphone.org/milestone/milestone4
[d] IMHO ticket #151 must be fixed before milestone4
      http://trac.freesmartphone.org/ticket/151
[e] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=495668#73
[f] after my mail at [e], I got in contact with Yue members, so things
    are moving :-)
[g] non-free is *not* Debian
-------------- 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/20081030/986483df/attachment.pgp