Thu, 09 Jun 2005

The tricky migration of GNOME 2.10 to unstable

You already know, GNOME 2.10 has finally started to enter sid. As always, this kind of transitions tend to break installability of GNOME in unstable during a few days. Please don't file bug reports about this, we possibly have enough.

Unlike our previous transition, which ended up going extremelly well, this time the Debian GNOME team is facing a problem that is delaying a few packages that are deep in the dependency chain, like gnome-menus or gnome-panel. The problem is, for those who care, that both kdelibs-data and gnome-menus provide the file /etc/xdg/menus/, which is part of the Desktop Menu Specification. After studying the specification and lots of discussion on IRC, we saw there were three ways to address this conflict:

In the end, after changing our mind we decided to go with the file renaming, as the "KDE in GNOME" (or viceversa) issue is way too ugly. This may or may not be a big problem in the Desktop Menu Specification, depending on who you ask. The spec was obviously written to have just one shared by all the desktops, but that's not feasible today, as it depends on a ton of desktop files to add the OnlyShowIn properties. When all or most desktop files in Debian have this, we might bring this up again.

Anyway, with gnome-menus sorted, we are near to be able to upload the final missing 2.10 core packages like the Panel or Nautilus. Most libraries and a good number of other Desktop applications are already in unstable, at least for i386. Other architectures will have to wait until the buildd's find their way through the maze of FTBFS due to missing build dependencies. Please be patient!

While all of this is going on, it's fun and nice to see azeem going over all the GNOME packages and quickly filing bugs about compile problems on Debian GNU/Hurd. If all goes well and the patches get applied on all the modules, GNOME 2.12 might have Hurd support out of the box for the first time.

(yes, the third alternative was a joke, no need to flame me about conflicting with KDE...)

Isn't this what Debian's alternatives system is intended for?

Posted by Matthew Dempsky at Thu Jun 9 22:16:34 2005

That would take us to the KDE in GNOME situation very easily, depending on where the alternative points to when you edit your menu for the first time.

Posted by Jordi at Thu Jun 9 22:29:51 2005

rpath Linux came to the same hackish solution.

Posted by Tim Gerla at Thu Jun 9 22:59:47 2005

Why should that file be owned by EITHER desktop? The whole point of the fd.o spec is to abstract the menus away from the specific desktop, so why would the be delivered by one desktop or the other? And doesn't this solution create inconsistent delivery? If there is patching to be done, it should be done to ALL desktop environments. Who knows, someone might decide to use the fd.o specs in GNUStep one day...


Posted by Matt M. at Fri Jun 10 01:58:42 2005