On Tue, 2006-09-12 at 21:06 -0600, Elijah Newren wrote: > 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],
I hear what you're saying, but actually the dependency on udev for the latest release is on version 082 which was released before February 27 2006, e.g. six months ago. One issue, however is the way distributions package up stuff, that's really out of my control. I do try to help out where I can but you still see some big distros shipping e.g. very old glibc kernel headers like e.g. Slackware. Specifically for SUSE and Fedora (which most HAL contributors are using / work for) there have never been problems if you use the newer releases and/or updates to older releases. Heck, even FC5 have the right libvolume_id stuff and recent enough kernels to make recent HAL versions work. So, there's also the distributor card one can play here, one could argue that some should be better about providing updates when updates are needed. > 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. Unfortunately this isn't possible as some of the features we want to implement depend on bug fixes and newly added infrastructure in the kernel. It's the only way we can sanely move forward without having tons of codepaths and not spend our time supporting bad old versions of our dependencies. The problem space HAL tries to solve just isn't as confined, well-defined or mature as either X.org or the kernel. I'm sorry I can't pull a white rabbit out of my hat, but there is really little to do about this. Ideally distributions would just release frequently, provide updates when needed (e.g. an udev package update with the required libvolume_id) and not ship software that is out of date. Now, I can't say what GNOME should do, but if we were to lock down the HAL version we use before way before a release there's really little incentive for me and possibly others to hack on software in that release. It would then land early in the next release, not exactly exciting and an incentive as I would need to keep in mind what features I can and cannot depend on. Finally, the HAL dependency in GNOME is optional. I don't think it's really fair to require the same level of stability as we do for glibc and X.org. Plus with one or two very minor exceptions (edge cases) we've kept the ABI/API since, huh, like 0.5.0 which was released 18 months ago (in so far the so name of libhal as not changed). > 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) Not to flame or anything, but we announced many many months (more than 6) in advance that it would go from the HAL tree. I'd blame my distro for not catching up / paying enough attention. I also don't see why GARNOME / jhbuild can't simply include a versioned udev dep that only provides libvolume_id. It's not like that would be rocket science. HTH, David _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
