A passionate openSUSE user
RSS icon Home icon
  • Enhanced typelib based dep generation

    Posted on December 7th, 2011 Dominique Leuenberger No comments

    A long time ago I posted about our inclusion of an automatic dependency generator for typelib() style provides and requires. The main goal there was to have the various seed and python based programs depending on gobject-introspection based bindings properly require the bindings, which also dragged in the libraries needed.

    For the openSUSE 12.2 release cycle we have to push this a little further: As the typelib namespace and version does not grow linear together with the shared library name, we have to split the *.typelib files out of the shared library package.

    An example why the typelib files need to be split out from the libraries:
    Clutter: the library was renamed from libclutter-glx-1.0.so.0 to libclutter-1.0.so.0, the typelib remained Clutter-1.0.typelib. The upgrade process is slightly ‘messy’ in this case and a bunch of problems could be avoided by splitting the typelib files out.

    But by doing so, this typelib package would really only have some typelib()-style provides, and no dependencies at all, other than the one the packager specifies manually. And there’s the catch: I’m by far to lazy to find/add the dependencies manually. Besides that: experience shows that this anyhow would be only done initially when a package is created and then ‘forgotten’ until a problem arises. Not what we need and want.

    So, I took some time yesterday, wrote a g-ir-dep-tool which loads a specific .typelib and checks for its dependencies. It catches other typelib style ones and also the shared library the tyeplib provides the binding for. Rather nifty and cool.

    I already integrated this into my GNOME:Factory branch, doing some final tests and cleanups. Once entered in GNOME:Factory nothing is going to stop us from splitting the typelib files out.

    And all this just to improve the quality of our packages and their dependencies.

    (All this work of course is not meant to be just for us, but has been submitted for review and inclusion to the gobject-introspection maintainers. So if all goes right, this will show up in some future release)

    Leave a reply