What’s cooking for the Application Manager?

Wednesday, 15. Aug 2007

I am trying out this blog thing, so that I can rant in color.

I work for Nokia on the Internet Tablet OS as a hacker, and that’s what I will be blogging about here. Or about whatever seems appropriate.

Our topic for today shall be a short introduction to the new Application Manager features in the next major IT OS release that are of interest to package maintainers. This stuff is documented in more detail here.

More .install file capabilities

A .install file can now instruct the Application Manager to add more than one catalogue.

You might have noticed that I don’t think that having as many repositories as we have now is a good idea, so please don’t take this feature as in invitation to spread your packages over many many repositories.  If at all possible, put your packages into the maemo Extras repository.  This repository will be preconfigured in the next IT OS release, and we will likely pay more attention to packages in the Extras repository when making new IT OS releases (when checking compatibility, for example).

You can now leave the distribution name blank in .install files and the Application Manager will provide the name of the current distribution.  This will work across backup/flash/restore: your catalogue will then automatically start using the new distribution name.

Catalogue names are now localizable.

Pretty names

A package can specify a (localizable) string that will be displayed in the Application Manager UI instead of the package name.

Upgrade descriptions

A package can specify a alternate (and localizable) description that will be used instead of the normal description when showing the package in the “Check for updates” view.  This can be considered as the end-user friendly version of debian/changelog.

Localizable descriptions

The normal description of a package can now be localized.

Support for Conflicts/Replaces

The Application Manager is still a coward when it comes to automatically removing packages to resolve conflicts, but it now will remove a package when another package is to be installed that both “Conflitcs” with that package as well as “Replaces” it.

Miscellaneous Flags

A package can cause the Application Manager to perform some special tricks.  For example, setting the “reboot” flag will cause a reboot after installing or upgrading a package.  Other flags cause the Application Manager to take a backup or close all applications.  These flags are mostly intended for updates to system packages, but you might find them useful.

Checking for free space before installing

A package can declare how much free space must be available in the filesystem before the installation is allowed.  The Application manager doesn’t dare to use Installed-Size for this since doing so is not reliable in general.


The Application Manager tries to keep track of where a package has been originally installed from, and will not allow updates to a package from a different source.  This means you can no longer replace IT OS packages by providing them with a higher version number in your repository.

Of course, you still can do whatever you want with your package.  Packages don’t get special privileges depending on where they are installed from.  These additional checks are only there to catch some confusing situations that are best avoided.


5 Responses to “What’s cooking for the Application Manager?”

  1. MDK said

    Web 2.0 got you! Nice that you started blogging finally.

  2. t3st3r said

    Sounds great.Few good ideas as well suitable for next-gen installers:
    – LZMA compression (see http://www.7zip.org).LZMA provides powerful compression but very fast in decompression and decompression requires quite few RAM and CPU.Once this algo combined with solid compression, same package could be up to 2-3 times smaller than current one.LZMA is open source and was ported to different platforms.

    – Delta updates.Well, there is people on GPRS and other slow or expensive links.Heavy downloads are not a great gift for these.As well as they’re require more bandwidth on server, etc.Why not to use same technique like Xdelta does, see http://www.xdelta.org.Once user has previous version installed, he can DL just small delta file and convert his old version to newer one.Delta files are often 10 times smaller than full packages

  3. Marius said

    dpkg 1.13.25 (which is what we currently have in Sardine) already supports LZMA.

    Binary deltas sound interesting, and could maybe be done like the existing *.pdiff support in apt-get. The probem that I see is that we don’t store the old package archive files on the device, so we don’t have something to patch.

  4. t3st3r said

    You do have old files! Here they are, just INSTALLED on the device. Executable and data files are never changed in normal circumstances so you surely HAVE files to patch – just apply delta to installed file so nef version of file is installed as the result. And one thing… if patch fails (installed file has been changed, etc) you can always fallback to non-delta scheme.

  5. Razvan Vilt said

    How about adding the support for installing/upgrading uninstalling multiple packages at a time (checkboxes on the left). It would make life a lot easier after a firmware upgrade.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: