The common theme of the changes is “policy”.  The application manager
has gained a lot more attitude and polices packages much more than
before.

Some of these policies have been designed by the Maemo community,
others not so much.  In my opinion, most of them are better off being
implemented in the Maemo package upload processes than in the
application manager.

I think it would be good to copy the rules into the Maemo QA process
and reduce the policy implemented by the application manager to a
simple “Does it come from the Maemo Extras repository” check.

Application categories

We finally managed to ship the category cleanups that had been
prepared for Diablo: The application manager has a builtin list of
valid categories, and any package that has a category not in this list
is forcefully moved to “Other”.

The list of categories is maintained by the Maemo community; see here for more information.

So if you find your package in “Other”, you should probably update its
category.

OS Update Protectionism

The application manager is still not as smart as apt-get or aptitude
when it comes to navigating the system out of a tight spot.  This
means that a application package can prevent the installation of a OS
update in obscure ways.

For example, if an application package depends on a specific version
of a OS package, and on that version only, then this OS package can
not be updated without first removing the application package.
Ideally, the application manager would explain this clearly to the
user and just do what is necessary after getting confirmation to
remove the application package.

The current application manager will just sit there and refuse to
help.

Instead of smartening up it, the application manager now checks for
some problematic dependencies and conflicts that could potentially
interfere with the next OS update and refuses to install packages that
fail the check.

If package X is a OS package, then a package will be rejected when it
declares one or more of the following relationships with X:

Depends: X (= version)        (or Pre-Depends)
Depends: X (< version)
Depends: X (<= version)
Conflicts: X (> version)      (or Breaks)
Conflicts: X (>= version)
Conflicts: X                  (well, couldn't be installed anyway)

Note that X must be a OS package for these rules to apply.
Technically, a package is a OS package when it is a direct dependency
of any installed package with the “system-update” flag.

If a package has one of these problematic dependencies, then that is
very likely a bug that should be fixed.

There is a Wiki page about this.

Erase-Everything-Reflashing tries to scare us again from afar.

Sometimes, a package can not be installed.  Maybe some of its
dependencies are missing, or there are unresolvable conflicts.  A
error message is displayed in this case.

If this happens to a OS update, the error message will now
tell people to reflash their device, like we did in times memorial.

I think this error message gives bad advice, and I am a bit worried
that it might be easily triggered by accident.

If you see this error message, please read it as “There is a bug
somehwere that prevents this OS update from being installed.”  We
should try hard to find this bug.

Let’s hope that the tighter policy checks will prevent this error message from ever being seen.

Installation from memory cards is no longer supported.

A new way of copying information has been invented recently, rather
blandly named “The Internet”.  We don’t know yet whether it will be a
success, but some people seem to be using it already.  It is not
unlikely that, in the not so distant future, most software will be
‘downloaded’ though a series of ‘tubes’ instead of being ferried
around on physical media.  We are watching this development carefully.

Installation of standalone Debian package files is harder.

You need to go to red-pill mode now to install a *.deb file directly.
We really want people to install packages from only very few, well
controlled sources, like the Maemo Extras repository.

Maemo-select-menu location has disappeared.

Just don’t use it.  In general, try not to perform any user
interaction during package installation.

25 0

Scratchbox is a success, and life has adapted to its kinks.  Our software has formed calluses around the places where Scratchbox used to cause pain.

If all goes according to plan, then the Maemo SDK will move from Scratchbox 1 to Scratchbox 2 in the near future.  This might require our software to develop calluses in new places, but that is OK.  The benefits of SDK+ will hopefully outweigh the cost of switching.

So I think this is a good opportunity as any to take a look at what Scratchbox and the Maemo SDK get wrong, in my opinion.

The big sin of Scratchbox 1 is wanton redirection to places that are outside the target.  The Maemo SDK inherited that sin without questioning it, and I am afraid the Maemo SDK+ will continue with it, even tho Scratchbox 2 would allow us to repent.

By way of example, consider how Scratchbox and the Maemo SDKs handle “autoconf”.

The nice trick of Scratchbox 1 and 2 is to put you in an environment that looks and feels like a native ARM machine (say) by emulating the CPU, but processor-hungry tools like the compiler are still natively fast.  This trick is achieved by provisioning alternative binaries of the processor-hungry tools. These alternative binaries are functionally equivalent to the real ones, but they use the instruction set of the native CPU, not the emulated one.  Scratchbox magically executes them instead of the real binaries and thus avoids the emulation overhead.

So, how would you expect Scratchbox to handle autoconf, which is a shell script?

I would expect Scratchbox to do nothing about the /usr/bin/autoconf script itself.  The desired speed up comes from having a alternative binary for /bin/sh, the interpreter.

Still, Scratchbox has autoconf in /scratchbox/tools/bin/ and accesses to /usr/bin/autoconf get redirected to /scratchbox/tools/bin/autoconf. Why?

The only reason can be bootstrapping or more generally, supporting incomplete systems.  This is another basic trick of Scratchbox: you have a running autoconf even when your /usr/bin is still empty.  This can be a great help when breaking the cyclic dependencies so typical of bootstrapping.

But, do we need the redirection magic for this?  After all, if /usr/bin is empty, the shell will not find autoconf there and will not even attempt to run /usr/bin/autoconf.  That’s why /scratchbox/tools/bin is included in your PATH by default, and autoconf and a host of other much more useful tools such as ls, cp, and mkdir are available to you from there even if your root filesystem is empty.

But, as soon as you have bootstrapped your system enough to have its own mkdir or autoconf, Scratchbox should step back and hand control over to the growing system.  The emulation magic of Scratchbox will make sure that the system’s tools can be used even when they are compiled for a different architecture.

Thus, redirection is not really useful for bootstrapping or incomplete systems, and should not be used to make ghosts of binaries available in places that are really empty.  Stepping back and handing over control can then be as simple as putting /scratchbox/tools/bin at the end of PATH.

This is not what Scratchbox does, and I frankly don’t know why.  It’s easy to fix, by changing the default path and redirection rules, but still it puzzles me why the defaults for the Maemo SDK are the way they are.  Defaults matter a lot when build bots enter the picture that run the Maemo SDK in its default configuration.

The way Scratchbox tries to stay in control of your growing system, you might think it is jealous and doesn’t want it to grow up enough to become independent.  With the current setup, you are bound to grow not only incomplete, but also inconsistent systems that are forever bound to run nowhere else but in Scratchbox.

As a simple example, some portable programs hardcode the location of perl into their scripts.  If you need these programs during early phases of bootstrapping, before you have added perl itself to the system, they will pick up /scratchbox/tools/bin/perl and will happily go to work bootstrapping the system further.  Later, after bringing perl into the system, you will retrace the dependency cycle so that the programs will now hardcode /usr/bin/perl into their scripts, the real location of perl in the system that you are building.  With the default Scratchbox, this is not what is happening: even on the second round, the programs will hardcode /scratchbox/tools/bin/perl.  This of course will not work when the program is running in a real Maemo device that only has /usr/bin/perl.

(Incidentally, some scripts in the Maemo SDK+ rootstraps still refer to programs in /scratchbox/tools/bin.)

Worse, Scratchbox’s Perl might be sufficiently different from the one you want to have in your system, courtesy of devkits being a notoriously hard to maintain and slow distribution mechanism.

The same thing continues to happen even if bootstrapping should be long over.  Essentially, what used to be a perfectly portable program has to changed to compile correctly in the Maemo SDK.  This is a useless activity, much more useless than making a program cross-compilable.

Thus, /scratchbox/tools/bin etc should be at the end of PATH.  But, that is not enough: Scratchbox will still redirect /usr/bin/perl to /scratchbox/bin/perl and you still have to fight against the core devkit.  Except now everything turns to magic, “which” is lying to you, and you can spend the better part of the day figuring out why things don’t behave the way you expect them to.

So, redirection is useless and harmful and the default PATH inside Scratchbox is wrong.

But what about the first trick, avoiding the expensive CPU emulation for processor-hungry programs like the compiler?  The speedup is crucial and it is worth to tolerate a bit of redirection ugliness to get it.  If we can get the speedup in a non-ugly way, that would be better.

The first important thing to realize is that the list of binaries to speed up can be quite short and very explicit: /bin/sh, the coreutils, /usr/bin/make, /usr/bin/perl, /usr/bin/m4, /usr/lib/gcc/*/cc1, /usr/lib/gcc/*/cc1plus, /usr/bin/as, and /usr/bin/ld should get us pretty far.  It might even be enough.  There is no point to try to speed up interpreted programs and libraries like shell scripts and Perl modules.  Bootstrapping is over, the point of redirecting /usr/bin/perl is to speed it up, not because we don’t have it yet.

The second important point is that to speed up /usr/bin/perl in this way, it has to be replaced with a functionally equivalent program. Same version, same compile time configuration, same everything except for the target instruction set.  Improving qemu to do some JITing with caching would be great.  Taking the configured source and compiling it again but this time for Intel is probably a more realistic approach for the time being.

In other words, I don’t want to use Scratchbox’s i386 Perl binary to speed up Maemo’s armel Perl binary.  I obviously want to use Maemo’s i386 Perl to speed up Maemo’s armel Perl.

I also don’t want to use Debian’s Perl to speed up Maemo’s Perl.  This is what the Maemo SDK+ is doing and it is equally as wrong as using Scratchbox’s Perl.

Scratchbox 2 is not so much redirecting executables, what it does is better described as assembling a new filesystem according to mapping rules.  It does this in a much cleaner and much more flexible way than Scratchbox 1.

What the Maemo SDK+ does with it, however, is to again shadow parts of Maemo freely and massively with things from outside of Maemo.  Almost everything comes from a Debian etch chroot.  Why?

This time, the reason seems to be that someone tried to learn a lesson from devkits.  Devkits are hard to keep up-to-date and people continuously complained about them being behind Debian.  So, the solution was to replace the devkits with Debian.

This is still missing the point, though: For people working on Maemo, Debian is just as hard to maintain as the devkits, even more so.  Just try to seriously answer the question which Debian distribution we should be using exactly for (half of) our build dependencies.  Stable? Come on, even devkits are more recent.  Testing?  Maybe, but why not unstable?  Maybe some packages from unstable and some from testing? Maybe people can decide on their own?

The complaint that devkits are out-of-date should be countered by removing devkits from the picture, but we shouldn’t stop there. General redirection to places outside of Maemo needs to stop.  Maemo itself should contain exactly what we need.  Build dependencies in devkits: bad, build dependencies in a distribution: hmmkay-ish.  Build dependencies in our own distribution: for the win!

We should not use Perl from Debian, we should use our own Perl.  It’s part of Maemo and not using it in the SDK is schizophrenic.  If we need something from Debian, we should import it and make it part of Maemo, explicitly and in a controlled way, like we have been doing it since the dawn of Maemo for packages that are primarily meant for the devices.

To put it another way: I want a simple setup that allows us to work on Maemo itself.  I don’t want a SDK that is a mix of packages from an old version of Debian and from Maemo, implemented via obscure and overly specific hacks to high level tools like dpkg-checkbuilddeps, and having to switch between under documented virtualization modes depending on whether I want to run “make all” or “make install”. Maemo can and should be big enough to contain its own build dependencies, and the virtualization tools should behave in a simple way.
So here is what I did as an experiment:

• I installed the maemo SDK+ with both diablo_4.1.1 rootstraps.
• I modified the configuration so that the armel rootstrap uses the i386 rootstrap as its “tool root”, and I disabled the gcc magic that Scratchbox 2 usually does.
• I wrote a new mapping mode for Scratchbox 2 that essentially gives you the following layout:
/ -> diablo_4.1.1_armel rootstrap
/home -> host
/dev -> host
/proc -> host
/sys -> host
/etc/passwd -> host
/etc/resolv.conf -> host
/usr/share/scratchbox2 -> host


At this point, you should have a working, fully emulated Diablo 4.1.1 environment. (Maybe this is the same as the “emulate” mode of Scratchbox 2, but I prefer to start from scratch in order to understand the magic better.)

You can compile stuff, but it is slow. Also, qemu is less than transparent and can’t seem to run /usr/bin/make, for example, which is a bit of a show stopper. Also also, find, xarg, and md5sum are missing and some tools expect /scratchbox/tools/bin to be there… oh well.

• The following mappings make native binaries visible inside the Scratchbox target:
/tools -> diablo_4.1.1_i386 rootstrap, read only
/opt/maemo/ -> host

• Then some symlinks for speed:
  
/bin/bash -> /tools/bin/bash
/usr/bin/make -> /tools/usr/bin/make
/usr/bin/m4 -> /tools/usr/bin/m4
/usr/bin/perl -> /tools/usr/bin/perl
• Also for Perl .so modules:
/usr/lib/perl/5.8/auto/File/Glob/Glob.so -> /tools/...
...

• For the compiler, I made a small wrapper since as a cross compiler, it doesn’t dare to look into the standard places for header files and libraries. This needs to be done more cleanly and more thoroughly of course and maybe I should be using Scratchbox’s magic instead. But for now I prefer it explicit:
#! /bin/sh
cc=/opt/maemo/tools/arm-2005q3/bin/arm-none-linux-gnueabi-gcc
$cc -I/usr/include -L/usr/lib -Wl,-rpath-link -Wl,/usr/lib "$@"


With this, “dpkg-buildpackage” runs successfully and with no real slowdown. I am happy.

Open issues:

• Fakeroot doesn’t seem to work. (I used the fantastic “sb -R” to get around this. Love it. But fakeroot just needs to be there as well for completeness.)
• The cross-compiler toolchain needs to move into Maemo and needs to be properly tuned.
• Some tools needs to be written to manage the symlinks, maybe in cooperation with the actual packages whose binaries we redirect.
• The Maemo warts need to be removed, such as the missing /usr/bin/find.

That’s it! Thanks for reading, and happy crossing!

14 0

Lintian is not happy.

Actually,

$ cat debian/rules
dh $1


works, too, since everybody seems to run debian/rules via /bin/sh anyway.
Lintian still not happy.

2 0

I have not heard the keynote and I haven’t seen a transscript yet, but unless proven wrong, I want to believe that Ari has been misunderstood: with enough determination, you can read what he says as an attack on the mobile phone industry: He might have wanted to say that parts of the Open Source and Free Software communities have a hard time imagining how utterly backwards and behind the mobile phone industry is.

(Just look at what happened when the 3G spectrum licenses were auctioned off.  Insanity.)

When Ari says “Why do we need closed vehicles? We do.”,  I read this as: “I know there are no good reason, only bad ones, let’s not waste time arguing about it and hope the bad reasons go away by themselves.”

When he says “As an industry, we plan to use open-source technologies, but we are not yet ready to play by the rules”, he can’t be implying that Nokia is not going to honor the licenses of code that they are using. They have to and they do.  Maybe he means that Nokia can not yet afford to speak out against DRM and device lock-down without being hypocritical, but he knows that people are hoping for such statements.

Yeah, I have nice rose-colored glasses.  I hope Ari clarifies his message in the near future.

(In any case, switching your code to GPLv3 seems like a good thing to do when you are worried about Nokia pulling a Tivo.)

Update: After taking off my rose-colored glasses, I saw this.  Well, what can I say.  Ari, I guess it is better if you let Quim do the talking.

4 0

It’s also quite easy:

• Put the device into R&D mode and disable the lifeguard reset.
• Make sure you have a lot of free space in / and/or move the apt archive cache from /var/cache/apt/archives to a memory card.
• Run apt-get install osso-software-version-rx34-unlocked in a shell that doesn’t die when the network goes down.
• Make some coffee, walk the dogs, plant a tree.
• Updated: Run flash-and-reboot and let it flash the kernel and initfs.
• File bugs.

I hope we can soon announce the repository that you need for this, but I can’t make any promises.

10 0

Summary: A dot-install file for package “<goo>” in “maemo Extras” should
look like this:

[install]
repo_name = maemo Extras
repo_deb = deb http://repository.maemo.org/extras/ mistral free non-free
repo_deb_3 = deb http://repository.maemo.org/extras/ bora free non-free
catalogues = maemo-extras
package = <goo>

[maemo-extras]
name = maemo Extras
uri = http://repository.maemo.org/extras/
components = free non-free

The only variable here is “<goo>”, the rest should be copied verbatim.
Specifically, you should not list any other repository besides
“maemo-extras”. (And make sure you have the trailing slash in the uri.)

Read on if you are bored or want to know why.

The maemo Extras repository is hopefully becoming the central place
where everyody is putting his or her maemo packages. The need to
access other repositories will hopefull decrease as maemo Extras
continues to grow.

Ideally, a OS2008 user only needs to open the Application Manager,
enable the “maemo Extras” catalogue, and will find a nicely
categorized list of applications and other add-ons that are painless
to install (and a joy to use, and easy to keep up-to-date, and
uninstall cleanly, and … you get the point).

One important inredient to make this happen is to make sure that your
package does not depend on other packages that are not also in the
maemo Extras repository or available in the OS2008 images.

That should be a pretty obvious rule. Think about the “use case”
above: someone enables the “maemo Extras” catalogue and will then see
your package in the Application Manager. If it depends on some
library that is only available in the SDK repository, it will not be
installable.

Thus, if your package depends on packages that are not already in
“maemo Extras” (and are not on people’s devices by default), you need
to get those packages into “maemo Extras” as well. Specifically, the
SDK guys should make sure that all packages in the SDK that might be
useful on the device sould be in maemo Extras, and maemo Extras should
also be pre-configured in the SDK.

You should not make a dot-install file for your package that lists all
the catalogues that are needed to find all the needed packages.
Specifically, you should not list the SDK repositories when you happen
to pick up a dependency to a SDK-only package.

That was actually the thinking behind only allowing one repository in
the original dot-install file format: everything needed to install a
package should be in the same repository as the package itself, or in
one of the repositories that everybody has pre-configured anyway.
Everything else is too messy. I am still not completely happy that I
let myself being talk into allowing multiple repositories now.

What you should do, though, if you have a dot-install file for your
package, is to list the one catalogue that contains your package (and all its
dependencies).

Also, all dot-install files that refer to the same repository should
do so in the exact same way. This will ensure that the Application Manager
will not have confusing, duplicated entries in its list of catalogues.

These two rules should be followed for any repository, not just “maemo
Extras”. Ideally, the software that places new packages into a
repository should also generate the dot-install files for it, in a
consistent manner.

Let’s look a bit at the options you have when describing a catalogue
in a dot-install file.

From the beginning, the dot-install file format allowed you to specify
different repositories for different major releases of OS20XX. This
allows one to specify for what OS20XX release a certain package is
available, and if so, where. The basic idea is that a single
dot-install file can be given to any user, regardless of what OS20XX
release he or she is running.

With the old dot-install file format, you could list one repository
for OS2006, and/or one for OS2007. With the new format, there is a
bit more flexibility, and thus more choice.

You can now list multiple repositories, and for each one, you can
specify for which major OS200XX releases it is valid. It will be
ignored for all others. Also, for each repository, you can specify
the distribution part of its sources.list entry explicitly, or you can
let the Application Manager provide a default value.

Thus, the most general way to refer to a repository is to make it
valid for any OS20XX release, and to let the Application Manager
provide the distribution. Such a description looks like this:

[repo]
name = Foo
uri = http://foo.com/
components = main non-free

Note the absence of the “filter_dist” and “dist” keys.

By using this general form, you more or less promise that there will
be a repository on http://foo.com for the “chinook” distribution and
all future OS200XX distribution names, and that that repository will
have your package in it. (If you want to extend that promise to
“mistral” and “bora” in addition to “chinook”, see the beginning of
this text for how to do it.)

This is the preferred thing to do. The rest of the flexibility is
mostly useful in specialized cases that are best avoided.
Essentially, you can control the error messages shown by the
Application Manager a bit for the case that your package is not
available for the OS200XX version that the user is running. I’d say
it is best to leave it to the Application Manager to come up with an
appropriate error message. It might not be perfect right now, but it
should and can improve.

From that point of view, the new flexibility of
dot-install files looks like a bad idea. Try to avoid it.

Simplicity wins again, as always.

7 0

There is one (small?) snag, though: the pre-configured catalogues are not backed up. This seems to be the right thing to do since we can assume that the new image has a better idea of what the pre-configured catalogues should be than the backup. Unfortunately, the maemo Extras catalogue is pre-configured as “disabled”, and thus, since it is not included in a backup, you always have to enable it explicitly after flashing.

Let me say that again: after flashing, you need to enable the maemo Extras catalogue before being able to restore packages from it. Unfortunately, the first-boot procedure doesn’t give you the opportunity to do this. What will probably work quite well is to perform the restore on first-boot to get all your settings back, but to not accept the offer to install the applications right now. Then open the Application Manager manually, enable the maemo Extras catalogue, and select “Tools > Restore applications…”.

That’s an accident, of course, it’s not by design. Sorry for that. We’ll figure out something for the next release. The easiest thing is to just include the “maemo Extras” repository in the backup, I guess. But then again, why not include all pre-configured catalgues? What do you think?

6 0

Today I want to excrete my approach to the tacky problem of what should be done about reaching the limits of limited resources. Please excuse my grammar etc since my IQ has temprorarily been reduced below that of aspell and I am not writing this with Emacs which reduces my degrees of mental freedom even more.

Users of the full Desktop experience that are running Gnome, KDE, Gnustep, or even fvwm on a modern piece of PC hardware don’t really have to worry about running out of resources. They configure their system to be adequate for their needs and generally accept the fact that running out of resources, while painful, is a problem that they have to solve by upgrading their system or by adjusting their choice of software to be more suitable. Thus is the life of the savvy computerer.

Running desktop software on mobile consumer devices, on the other hand, poses the immediate challenge of how to cope with limited resources in the hand of users that shouldn’t care less about the amount of RAM they have. Today, it is accepted that owners of an iPod make an informed decision of how much storage that glorified mp3-decoder-plus-amplifier has, but actually, Apple knows the customer and is marketing the things in t-shirt sizes: hundreds of songs, thousands of songs, millions of songs,

The point being: people understand that devices have a limited amount of resources and that more is most of the time better, but how much they really need in hard MiBs is quitet the mystery. But still, running out of resources is not a surprise. Everybody is used to running out of monay after all.

When it happens, tho, the experience of actually running out of space should be so pleasant that you go and buy the next bigger model instead of giving up on the whole fad of digital entertainment entirely.

In my opinion, Unix has done quite well with coping with limited resources, AS LONG AS there is a knowledgable system administrator available that can migrate home directories to a bigger disk array, etc.

But what about devices like the Nokia N800 that attempt to put half of Gnome in the hands of Joe Couchpotatoe, without a sysadmin to be found?

When Joe runs out of resources, he is not going to check /var/log/messages and order a bigger flash chip from Samsung and solder it in. Unless he is convinced that he just requested something impossible from his device, he is going to catapult his device into a corner and write an angry blog post about it. (Oh, how I miss the days when posting something to the whole world required more skill than piggybacking some memory…)

So, finally, what can be done about running out of resources? The following is what I have written into a bug report about GConf behaving erratically when there is no storage for it it save its database. I would like the maemo architecture to evolve along these ideas…

Operations, regardless of whether they consume memory, storage, or CPU time, can be broadly classified into “small” ones and “large” ones. Small operations are expected to consume a small amount of resources and not having this small amount available is considered to be a pre-condition violation. Large operations are the ones that are expected to consume huge amounts of resources which might or might not be available. What happens when you run out of resources is part of the defined behavior of the operation and will be handled in the normal course of action.

Examples for small operations are allocating memory for GObjects, writing your PID into /var/run/, and computing the length of a string. If there are not enough resources available for these operations, drastic things are allowed to happen, like the process aborting, or not being responsive for so long that the user is tempted to kill it.

Examples for large operations are generally associated with external data: allocating memory for a user-supplied image, downloading a file to local storage, or applying a filter to a image. If these operations run out of resources, they should handle it gracefully with proper progress bars, clear indications to the user and options for the user to repair the situation and try again.

The system as a whole is responsible for dealing with small operations running out of memory. When memory gets tight, the system should warn the user about it and offer some ways out of it. Starting to swap, background killing, popping up a dialog that lets the user close some applications, etc.

The same should apply to running out of storage for small operations: the system should warn the user when storage gets dangerously full and offer some cleanup options (like moving user documents from internal flash to a memory card).

We are quite some way away from making this work perfectly, and applications don’t give indications whether they are doing a “small” operation or a “large” one. I.e., the memory allocator in libc should know whether it has to try its damned best to satisfy the request, or whether it might fail it so that other more important requests might be fulfilled later.

Likewise, there should be reserved storage for small operations. (The distinction is not between “root” and “user”, with the implication that root operations are somehow more important than user operations.) Large operations should not be allowed to consume the space reserved for small operations. When that reserved storage starts to be being consumed by small operations, the system should go into “the ship is sinking” mode and urge the user to make space.

Now, is writing the GConf database a small operation or a large one? In my opinion it is small. Size is not really the main deciding factor (and so “small” and “large” might not be the best terms for the two classes of operations). Writing the GConf database is not a operation that the user initiates or is aware of. GConf must handle it completely transparently and must thus rely on the system to get it out of a tight spot. In the rare case that writing the database actually fails, the user should have been amply warned about the system becoming instable etc, that it is acceptable to loose the
unsaved user settings.

Our system doesn’t do anything right now to make small storage operations more robust, but I don’t think we should put any workarounds into GConf for this. When writing the cache fails, it must happen in a controlled and sensible way, of course: the old database that has been stored must not be lost and GConf should continue working.

4 0

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.

Domains

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.

11 0