Doug Goldstein

While the D-Bus big whig developers Havoc Pennington and John (J5) Palmieri have been working hard at bringing us a 1.0 release, steev and the rest of the Gentopia gang have been working hard at bringing you some of the pre-1.0 releases to the Portage tree. There are some snags and roadblocks along the way.

• With D-Bus-0.90 (pre-1.0 beta1) and higher the D-Bus bindings are broken out from the main package. This means that packages will now have to depend on their specific bindings rather then D-Bus itself, so all the depends in the Portage tree need to be updated. The following depend is correct: || ( >=category/binding-0.71 ( =sys-apps/dbus-0.60 or 0.33 ) )
• As a warning note, dbus-core is now called “dbus” yet again as of version 0.94. A move entry has been put into the tree to help people migrate but once again, the package is masked. I really don’t want to hear it if it breaks your system or rapes your cat. It’s a masked package, if you can’t deal with the breakage and fix the two pieces, you shouldn’t use it anyway.
• Since the bindings are broken out of the main package, upstream has chosen to maintain only the specific ones they use. Since John and Havoc are Gnome guys the glib bindings received official love and since Gnome people love Python, the Python bindings have received love as well. The rest of the bindings have been cast off like redheaded step children, especially the Mono bindings which are making a come back as dbus-sharp. Trolltech has taken up the QT4 bindings, which have some issues but since my job at work involves commercial Trolltech licenses I was able to kick some dbus issues right to the guys where it needed to go. The last set of bindings are the qt3 bindings, which we’re just using a copy of the old qt3 bindings for now.
• D-Bus upstream has currently 7, possibly 8 items on their list prior to their release. They’re saying none of these will involve functionality/compatibility breaks but it sure sounds like it. It’s really starting to feel like it was suddenly decided that dbus needs to move to 1.0 and it needs to be there NOW but without any planning going into what it’s actually going to take or the time frame or the testing required. (see HAL issues towards the bottom)
• D-Bus will require a rebuild of anything linking to it since the libtool so version # has changed.
• Applications need to get ported to the new bindings since now people have either re-written or re-factored bindings which now makes some work and some break.
• API deprecation. The stuff deprecated from ages ago in D-Bus has finally been dropped. A LOT of packages are going to be caught off guard by this one, even HAL was caught off guard and the same maintainers that maintain D-Bus are part of the HAL project.
• David Zeuthen and his ever changing HAL depends and goals and targets which fails to get documented properly anywhere… “We need pam_console this week? PolicyKit next? hal-info the week after that? Wait.. that data won’t be in HAL… oh wait… now it is… but wait.. let’s move it’s location. Oh well Redhat doesn’t feel like HAL should provide that any more so you will have to have an external app provide that data… sure we know that lots of HAL consuming apps require that data and will now break but we’re going to ship this release without it. We’ll provide an external application, only in CVS because it’s no where near stable that will provide HAL with this data…” This has lead to at least one issue between me and Aaron Bockover, author of the popular Banshee, which I use personally, where each of us insisted we were doing it right be referring to different parts of the HAL docs

Filed under: General, Gentopia, Linux

Leave a Reply