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

Luca Capello luca at pca.it
Mon Nov 3 00:13:24 UTC 2008


Hi there!

On Thu, 30 Oct 2008 19:56:44 +0100, Luca Capello wrote:
> 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?

I would prefer fso-config-general, since the idea is to have one
fso-config-* package for each $DEVICE, thus 'general' = no specific
device.

>> 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:

I was reconsidering the idea of an fso-config-general package,
especially after having realize that each fso-config-* package acts as a
metapackage:

  http://lists.alioth.debian.org/pipermail/pkg-fso-maint/2008-October/000268.html

> 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 :-(

I have never tried, but I think that we are already in this apt-get
situation: what happens when install-recommends is on and apt-get wants
to install a virtual package?  fso-frameworkd recommends both the
fso-config and fso-sounds virtual packages.

However, I still think that fso-frameworkd should not depend on the
fso-config virtual package: this helps a lot people who want to fully
customize their Debian, becuase they are not obliged to install any
fso-config-* nor fso-sounds-* package.

> 2) what should be put into that package?  The generic frameworkd.conf
>    file?  In this case the package would be useless, [...]

While I think we all agree that a whole package for a single file is too
much, at the same time the situation is a bit different: in the end I do
not think that fso-config-general will ship more than one file, but this
is perfectly fine for a metapackage ;-)

If we want an fso-frameworkd package generating all the necessary
packages, then fso-config-general could depend on fso-sounds-none:

  http://git.debian.org/?p=pkg-fso/fso-frameworkd.git;a=commitdiff;h=f62d50e3fe5faf800b49a145d3369985aadd330b

>> 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.

Let us face reality: the transition to a device-agnostic fso-frameworkd
will not be smooth, in any case :-(

>>> 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.

This is now being discussed at:

  http://lists.linuxtogo.org/pipermail/smartphones-userland/2008-November/000352.html

>>> 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.

FYI Yue sounds are now ready and I will start working on the package in
this week.

We must take two decisions: should we add an fso-config-general (or
whatever other name) package?  And once that decision taken, should we
release the device-agnostic fso-frameworkd as it is or should we wait
for the 'frameworkd-rules' tool?

My vote goes for releasing, since then we will be able to focus on
uploading to main and spot any problem before the packages reach main.

Thx, bye,
Gismo / Luca
-------------- 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/20081103/d949426f/attachment.pgp 


More information about the pkg-fso-maint mailing list