On 9/27/2010 8:59 PM, Alistair Buxton wrote:
On 28 September 2010 00:41, Eino-Ville Talvala<talv...@stanford.edu> wrote:
Hi,
I have a question about how extras packages not in the user/* hierarchy
interact with the application manager and updating.
As part of the FCam API, we have a package, fcam-drivers, which replaces the
built-in camera driver modules with slightly modified ones. Previously, I've
been listing it under user/Multimedia, but it's been made clear that that's
against packaging policies, since it's not a end-user application.
So, when we made a few minor bug fixes to it recently, I changed the section to
'utils', since there didn't seem to be any guidance on non-user/* section
names, and that's what some other kernel-modifying packages use. I uploaded
fcam-drivers 1.0.7 to extras-devel a few hours ago.
However, I haven't received any notification in the N900 interface to update to
the new package - I only have extras-devel enabled, and 'apt-cache pkginfo
fcam-drivers' lists the new version 1.0.7. 'apt-get upgrade' does tell me it
will upgrade fcam-drivers, but Application Manager doesn't know about any
updates.
Is this the expected behavior, or has the section change caused a problem? I
know that non-user/* packages won't show up as installable, but if they don't
appear as updateable either, how do we distribute bugfixes to fcam-drivers, for
example, if the only way end users will get the update is through an apt-get
upgrade?
(correcting accidental off-list reply)
H-A-M will never notify you of an update for a package that is outside
of user/* so you must upload a new version of fcam with an explicit
dependency on the latest version of fcam-drivers. The user would then
see an update for fcam, and installing that would force the updated
fcam-driver to be installed. You must do this every time you want to
update fcam-drivers, even if you didn't modify the fcam package at
all. It gets worse if you have multiple packages that depend on some
library - you would have to bump every dependent package to make sure
everyone gets the update. This is, apparently, by design.
If I'm thinking this through right, it's actually worse than that. The
FCam dev library is small and statically linked, so the it's the
applications themselves that have a dependency on fcam-drivers. So to
guarantee that everyone who's using fcam-drivers gets an updated
version, all applications that use it must release new versions with new
version numbers for fcam-drivers, since any given user may have only one
such app installed.
Since FCam is a publicly-available API that we're trying to promote,
we're expecting third parties to write applications that depend on
fcam-drivers. That means not all apps will be ours, and we can't do the
update for them, leaving some users with buggy versions. Already, the
HDR and low-light programs are apps by our collaborators at Nokia
Research, and I don't have any ability to update them.
This seems like an unfortunate situation in terms of bug fixes and so on
- we think fcam-drivers is pretty stable, so hopefully we don't have to
update it again anytime soon!
Eino-Ville (Eddy) Talvala
Computer Graphics Lab
Stanford University
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
