- (simbab) wrote in debian,

  • Mood:

dpkg question

A lot of new GTK+ applications require a version of GLib that is more modern that the 2.12 version included on the ITOS2008 software for the Nokia N800 Internet Tablet. ITOS2008 is based on Maemo 4.1/Debian etch and uses APT and dpkg. For example, Midori 0.2 requires WebKit 1.1.15 or newer, which in turn requires GLib 2.21 or newer. Midori is significantly faster on the device than the included Mozilla browser.

I am trying to update the glib version but running into a problem: there is a meta-package on the system, called osso-software-version-rx34 (OSSO is Open Source Software Operations, which is the internal Nokia department that handles Maemo, and RX-34 is the product code for the N800), that depends on the exact versions of system libraries, including libglib2.0-0, that ship with the device. This is similar to Ubuntu's ubuntu-desktop package.

Does anyone know creative solutions do not break this while still upgrading the package? Somehow, I need to replace the files in libglib2.0-0 with those in a different package, without triggering overwrite errors in dpkg. Will using a Replaces: or Provides: field work, in terms of not breaking dependencies? I'd like to have something like, libglib2.0-0-custom version 2.24.0 that replaces files in libglib2.0-0 2.12-1ossowhatever, but that package still needs to exist in that exact version on the system when all is done.

Yes, I know I am playing with fire here but worst case it is very easy to re-flash the device back to stock ITOS2008. I have used the builtin OSSO Backup to backup to a memory card and ensure I don't lose any data.
  • Post a new comment


    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 1 comment
I do similar stuff to this with RPM all the time. As I understand the dpkg format it should work just about the same way, but I haven't worked with that in a while.

Basically I use two different packages, libfoo and libfoo-old, each of which provide their own versions of /usr/lib/libfoo.so. libfoo provides version 2.0 so that any other packages which depend on that specific version will be happy while libfoo-old includes versions 1.0, 1.1 and 1.2. Since they have different package names, don't install any overlapping files and don't explicitly replace or obsolete one another there's no problem with having them both installed and any packages which depend on them should require specific versions of the shared library (libfoo.so.1.2 or libfoo.so.2.0) rather than package versions like libfoo-2.0.

If that makes any sense.

If all else fails then it is still possible to install whatever you want using tags like --ignore-depends or --force-depends-version, but that can make things a little weird the next time you try to update things.