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/applications.menu, which is part of the
freedesktop.org
Desktop Menu Specification.
After studying the specification and lots of discussion on IRC, we saw there
were three ways to address this conflict:
- Use
$XDG_CONFIG_DIRSin the user's session to look for the menu files elsewhere. This has a big drawback: if someone is using KDE and uses a menu editor to tweak their KDE menu, they will get a~/.config/menus/applications.menuwith a full KDE menu layout. Now, if this user switches to GNOME, GNOME will read this menu in their home, so they will get a KDE menu in GNOME, which is not so funny. - Add a prefix to the GNOME-provided file, to make it read
gnome-applications.menu, and patch GNOME menu editors, the Panel and other apps to look there. The big drawback is that third party apps with menu-editing functionality, not provided by Debian, will not be aware of this and will write custom menus in the wrong spot. - Make gnome-menus (and effectively, all of the GNOME desktop) conflict with KDE. This great idea was suggested by dato, but at the time we had to make the final decision, he was inexplicably quiet on IRC, so we had to discard it.
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 applications.menu 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...)
