Backporting apt and hildon-application manager…

…or, a failed attempt at breaking OS2008!

Recently, I’ve been mildly annoyed by an application manager bug, namely this one: A long version field making only a very small portion of the name shown in the list of available packages.

Seeing that it’s supposed to be fixed in the next version of ITOS, I decided to go on the wild side: What about trying to compile the SVN version of application manager? The source is on garage, and can be checked out with svn checkout https://garage.maemo.org/svn/hildon-app-mgr.

Trying to compile it in scratchbox, I found I needed a newer libapt-pkg-dev-package than what can be found from the
repositories. So, off hunting for newer version of apt, which I found here. And it compiled without a hitch – so I upgrade the scratchbox apt, apt-utils and libapt-pkg-dev to version 0.7.6maemo3-unreleased. And we’re back to hildon-application-manager compiling.

hildon-application-manager now compiles! And also installs in scratchbox. So, now it’s time to get really adventurous: what about on my n810? The apt and apt-utils packages installs without a hitch, but – nuts, the hildon-application-manager package conflicts with hildon-update-notifier, that is required by a bunch of packages I don’t feel like uninstalling. And now, my old hildon-application-manager no longer works. I’m starting to feel like this was a bad idea – but I had half expected it when I started.

So I start digging around, and find that there’s no overlap on any files in what’s provided by hildon-application-manager and hildon-update-notifier. But hildon-application-manager now includes a file libhildon-update-notifier.so! Digging around in the debian/control, I see that it’s specified there: It conflicts with and replaces hildon-update-notifier. Aha! So it has simply included it in the application itself. But seeing that it doesn’t actually conflict with any files, I decide to get more experimental: I removes hildon-update-notifier from the Conflicts: and Replaces: field, and rebuild the package. And now, it even install on the device.

It’s worth to note that it probably conflicts with osso-software-version too. But I had already uninstalled that package when I installed the RTCOMM beta, so I wasn’t too worried about that….

But, installing isn’t all, I was more interested in whether or not it actually worked. And I’m happy to say, it does! I’m not sure I can recommend this route for anyone that wants to walk on the safe side of the road, but so far, I have not noticed any problems using it. And it did actually solve my problem with the long version number 🙂

So if you feel like walking on the wild side, either compile it yourself (it’s a good introduction to simple scratchbox development), or download the packages here:

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert.

Dette nettstedet bruker Akismet for å redusere spam. Lær om hvordan dine kommentar-data prosesseres.