Re: external dependencies

[David Zeuthen <david fubar dk>]

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