A combination of responses... > So, what's the procedure going to be for requesting GNOME to depend on a > new HAL release? I mean, when is the latest point in the release process > that modules in GNOME can require new HAL releases - up until now, I > just worked with the respective GNOME module maintainers to figure this > out, perhaps we want to formalize this a bit.
I put a proposal for just such a method up at http://live.gnome.org/TwoPointSeventeen/ExternalDependencies; to quote from there, the process I'm proposing is: "These are the versions of external dependencies that Gnome modules may depend upon. If you find a Gnome module depending on a newer version than the one listed here, feel free to file a bug. Note, however, that this page can be updated at any time by the release-team. If you want one of the versions updated, make a good case for it on desktop-devel-list. In particular, provide reasons why it is important to bump the version number and any impact (compile and run time) on other modules." > > and libvolume_id? > > This comes with recent udev releases. Suggest to just ask users to > install it (it's libvolume_id-devel on Fedora) much like they are asked > to provide glibc and other low-level development libraries etc. It is much like glibc and Xorg, but there is a bit of a difference here. With hal 0.5.8, you're depending on a version of udev so new that no recent distro releases have it[1], whereas with glibc and Xorg we tend to not allow hard dependencies on anything that won't already be pretty universally available. Ideally, I'd like us to be able to depend on distributor versions of dbus and hal, just like we do with glibc and Xorg. It'd improve buildability of Gnome and cut down on hacks to launch a proper Gnome environment (stuff like sudo service stop messagebus in the appropriate xinit scripts once /etc/sudoers has been edited appropriately and such). In other words, it'd be one step towards helping us make Gnome dogfoodable again (and no, it currently isn't[2]). I understand that depending on distributor versions of dbus and hal may not be feasible yet, but I'd really like to move in that direction. > Also, this will certainly make it easier on the distributions since they > won't have to ship HAL git snapshots or cherry pick patches just to get > the latest GNOME release working. And many people who are trying to build development versions of Gnome (e.g. testers, developers, etc.). :-) Elijah [1] Irc log time, from #gnome-hackers: Sep 11 21:35:47 * jamesh wonders if davidz really wants people to test new HAL releases Sep 11 21:38:15 <jamesh> I have a distro released 3 months ago, and it doesn't have a new enough udev to compile hal Sep 11 21:39:02 <desrt> linux desktop development is getting breakneck these days Sep 11 21:39:39 <jamesh> sure. But he could have left the cut-n-paste libvolumeid in there a little longer (preferring a system version if found) [2] http://mail.gnome.org/archives/desktop-devel-list/2006-August/msg00113.html is one recent example pointing this out. _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list