[pkg-fso-maint] fso-config-gta02 is ready!

[Luca Capello]

Hi there!

On Fri, 10 Oct 2008 11:33:06 +0200, Luca Capello wrote:
> On Fri, 10 Oct 2008 09:35:03 +0200, Joachim Breitner wrote:
>> Do you really need the conflict against the lower version when there is
>> a dependency on the higher one?
>
> I don't know, that's all.

After having discussed on d-d [1], it seemed that the conflict wasn't
needed and indeed I removed it [2].

Then I performed some tests and I was quite surprised that
fso-config-gta02 was unpacked even with the wrong fso-frameworkd
version.  Then the installation couldn't complete for obvious reasons:
the files provided by fso-config-gta02 was already provided by
fso-frameworkd.

This situation was solved putting again the conflict [3]: now if
fso-frameworkd isn't at the right version, fso-config-gta02 is not at
all unpacked.  Since I forgot that I already put the conflict before, I
forget to just revert the first patch (nothing wrong, but since I tend
to be a perfectionist...).

>> Upgrades won’t be smooth unless you handle the removal of the conffile
>> in fso-frameworkd: Check in postinst whether you are upgrading from a
>> version with /etc/frameworkd.conf, and if it wasn’t modified, delete
>> it.  If it was modified by the user, rename it. (This is rough
>> knowledge, better ask on #debian-devel).

> Thank you for the having brought this issue up, I completely missed it
> and then this morning during a wishful thinking (taking a shower...) I
> thought about another similar problem: if we don't depends on
> fso-config-gta02 (or any other virtual package), there's no easy way to
> upgrade.  This because the new fso-frameworkd version won't provide
> anymore the config files (in /etc and scenarios).  The same is true for
> the sound package which is WIP.

After having worked on it, the situation between fso-config-* and
fso-sounds-* package is different: while the former is *necessary*
(because without there's no /etc/frameworkd.conf and thus frameworkd
cannot start), the latter is not, since e.g. the phone can still vibrate
(and the error frameworkd generates is not fatal).

For this reason, fso-config-* packages must depend on fso-frameworkd,
while fso-sounds-no don't.  OTOH fso-frameworkd doesn't depend on any of
the two, but only recommends both.

> For the reasons already explained [2], I'd avoid a dependency and just
> put a note into NEWS.Debian as well as in the debian/changelog.  The
> other solution being the dependency, which can be removed later on.

Committed [4].

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://lists.debian.org/debian-devel/2008/10/msg00510.html
[2] http://git.debian.org/?p=pkg-fso/openmoko-files.git;a=commitdiff;h=f8624e6c7da3adbdac18f66de08109526170f5cb
[3] http://git.debian.org/?p=pkg-fso/openmoko-files.git;a=commitdiff;h=8bca20f669df109b6bbecc9c177562987e0bc508
[4] http://git.debian.org/?p=pkg-fso/fso-frameworkd.git;a=commitdiff;h=80745aee9eaefaabe91a95a4314c3ca9663dd8a1
-------------- 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/20081027/b5fa44ce/attachment.pgp