[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