[arch-dev-public] GNOME 2.28 - changes ahead

[Jan de Groot]

There's a release of GNOME 2.27.90 scheduled for this week, which means
that GNOME will enter a code freeze. This is the point where I usually
pick up packaging the next major version.

For GNOME 2.27/28, some things will change in the distribution:
- DeviceKit-Disks (new package)
- PolicyKit 1.0 replacing 0.9
- PulseAudio (new package)
- Esound

DeviceKit-Disks will replace the functionality that used to be provided
by hal. GNOME will no longer use hal for this. I don't know about KDE,
but I think they will follow soon. Hal will stay alive, but it has
received deprecation status upstream, which means that only bugfixes
will get applied, no new features anymore.

My plans are to replace PolicyKit 0.9 with 1.0 completely. Yes, they can
be installed side-by-side, but I don't like to have a deprecated policy
framework on my system. Any application depending on PolicyKit needs to
be ported. Fedora has patches available for most of them.
In case of KDE and GNOME: both support PolicyKit 1.0 in the latest
versions, KDE 4.3 and GNOME 2.27/28. The only package that I know of not
supporting PolicyKit 1.0 is hal.
Hal will get a special treatment: removal of PolicyKit interaction. The
next version of hal will use an at_console ruleset. ConsoleKit has
backwards compatibility for this. I don't want to return to the group
setup we had before. Since Udev 145 will use ACLs once our initscripts
mount /dev/ on tmpfs instead of ramfs, a ConsoleKit login will create
ACLs for access to devices on /dev. This means users don't have to be
member of any group to listen to sound, use DRI or write CDs once this
is changed. Enforcing group membership to hal users would be a stupid
thing to do then.

Then there's PulseAudio. Though I still don't feel the need for this one
on the systems I own, a lot of users have requested this. PA has matured
a lot in the meanwhile, and PA is more than just an ordinary ESD
replacement. 

Another issue is ESD. This package is not really maintained upstream
anymore, and I don't think it makes sense to have two sound servers as
dependency for one desktop. Given the fact that Fedora disables esound
support since 2.23.4, I think it won't be a problem to remove it from
the dependency chain. Esound will stay in the repositories, but won't be
used by GNOME as sound server anymore.