What’s cooking for the Application Manager?

Wednesday, 12. Aug 2009

I am no longer closely involved with the venerable, aging, and often renamed Hildon Application Manager; Víctor has very successfully
stepped into bigger shoes and is maintaining it now.  Nevertheless, I
can’t stop myself from giving a brief rundown of its new Fremantle
features.

Development has moved to Gitorious, so you can check the detailed
history there.

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.

About these ads

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

  1. timsamoff said

    Interesting changes.

    This scares me a little:

    > Installation from memory cards
    > is no longer supported.

    Your joke is a funny one, but there have been several instances where I’ve needed to install something from physical media. Likewise, I have had a .deb sent to me via Bluetooth where there was no wifi access.

    But, anyway…

    • Marius said

      > This scares me a little:
      >
      >> Installation from memory cards
      >> is no longer supported.
      >
      > [...] there have been several instances where
      > I’ve needed to install something from physical
      > media.

      Yes, but I am pretty sure nobody has ever prepared a ‘auto-install’ memory card for this. The AM would recognize such a memory card and offer to install packages from it pretty automatically.

      If you have to perform repairs or other power user package management, I hope it is good enough to do them using apt-get and dpkg.

      The ability of the AM to install a raw *.deb file in red-pill mode is only there because it might be the only way to give you a terminal, by installing ssh or osso-xterm, say.

  2. X2 said

    You did it. Sweet.

  3. lauren said

    so maemo app store here we come no? freedom be damned!
    *sigh*

    • Marius said

      No, no, you could say “Maemo distribution here we come, package mess be damned.”

      You still have all the freedom you had before; you can still configure any and all repositories you want, and *.install files are as powerful as before (minus the “card-install” feature).

  4. timsamoff said

    Ah, ok… Not quite as seamless, but it works. Thanks for the response!

  5. steve-o said

    “We really want people to install packages from only very few, well controlled sources, like the Maemo Extras repository.”

    I wouldn’t call the Maemo Extras repo “well controlled.” I especially like the classy touch of “Navigation” being a category right next to “navigation,” as well as the fact that half the time you have to click ‘install’ from maemo.org, as the package doesn’t even show up in Extras.

    Either let us install whatever the hell we want or else make Extras less of a ghetto. Everything else is a waste of time, and it will alienate users.

    • Marius said

      I think both your wishes have been granted:

      Maemo still is a open platform. You can always fork and do your own thing. The fundamental freedom to install whatever you want has not (yet) disappeared. Yes, we think we know what’s good for you, but if you disagree, we wont stop you.

      Also, Maemo Extras is doing great, as Andrew points out. Please help to improve it even more.

  6. steve-o, the fact you can get “navigation” and “Navigation” has been addressed by Marius above.

    And Extras *is* becoming more well-controlled. Fremantle has provided the opportunity to introduce an “extras-testing” alongside “extras-devel”. There are both automated and volunteer-based QA checks necessary now for something to get all the way up to Extras.

    http://maemo.org/packages/repository/qa/fremantle_extras-testing_free_armel/

  7. steve-o said

    That “you can always fork” attitude will be the death of open source. I can’t “fork” the extras repository. Come, let us be reasonable. Furthermore, I don’t see how the nebulous suggestion to fork a repository “addresses” the fact that things as fundamental as case sensitivity have not been remediated at -all- in Maemo Extras. Unless, of course, this is a “fixed in fremantle” situation and we Diablo users can (once again) go to hell for all the maemo devs care.

    If you’re talking about forking the entire distribution, don’t be asinine. The Mer folks are already doing that, thank God.

    The introduction of extras-testing only tells me that now the process to submit an application to Extras will be more confusing, which just makes the barrier to entry higher. Not that you have to be some kind of genius to work it, but I have several apps on my NITs that I don’t release — specifically because it’s such a pain to deal with the ridiculous bureaucracy that results in a shoddy, difficult-to-navigate Extras repo.

    Honestly, I can’t be bothered to port any of my programming to Fremantle, because the SDK is even clumsier than diablo’s scratchbox, and I know Nokia’s just going to drop it like a hot rock a couple months after it’s out.

    I do, however, congratulate you on managing to build a community around an ‘open’ OS developed by such a tight-lipped not-invented-here company, and I don’t want anyone to stop the work they’re doing. Just stop focusing on trivial garbage like maemo-select-menu and work harder on the process.

    And if anyone knows if I can send a check to Nokia to un-disown (repossess?) Diablo, send me an address. I’m not fond of abandonment.

    • Marius said

      The “you can fork” attitude has two sides to it:

      On the one hand, the ability to fork something is the heart and soul of Free Software and Open Source. If you can’t fork it, it is not free enough. If you want people to commit to your project, it is paramount that you allow them to fork it, to take away the fear of losing their investment.

      On the other hand, the actual practice of forking can be damaging. It usually is not because one of the branches will in all likelyhood die quickly (or there are good reasons to keep both branches alive).

      When I said, “you can always fork”, I was trying to point out that the new policies of the Application manager do not make the platform more closed. You can always write your own Application manager that is less restricted (and put it into Maemo Extras).

      But I am quite convinced that a fork is not necessary. The new policies do not affect what I would consider “normal use”. (The most brutal one of them, the enforcing of categories, was actually requested by the Maemo community.)

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: