Re: external dependencies

["Elijah Newren" <newren gmail com>]

On 9/12/06, David Zeuthen <david fubar dk> wrote:

I think I may have come across much too harshly.  Sorry about that.

> 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.

...AND didn't do the appropriate fact checking.  Doh!

> > 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.

Yep, that makes sense.  As I mentioned before, depending on
distributor versions of dbus and hal almost certainly isn't feasible
yet, I'm just hoping to move somewhere in that direction.  It makes
sense that we're going to have to strike a balance somewhere
inbetween, and that balance may well be more on the side of the
bleeding edge right now.  (Note, though, that there is also the
possibility of making Gnome modules optionally depend on newer
features of external dependencies instead of having hard dependencies
on the newer versions, so we have a bit more leeway than either-or.)

> 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.

I'm not proposing that external dependencies be considered entirely
locked down at the beginning of a release; in fact, I wouldn't mind
dependencies being updated several times throughout a cycle--if
merited.  All I'm proposing right now is that bumping dependency
versions should first come with a proposal to the community weighing
the pros & cons & impact, and that sufficient time is provided to try
to avoid introducing new build issues where possible.  Further, I
think such proposals should be allowed at any time through the cycle
(though there should be an exceptionally strong case to update a
dependency during e.g. hard code freeze).

> 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).

Agreed; I do hope things will move in that direction, though.  D-Bus
is in a similar position, though I think it is probably closer to
being able to provide such a level of stability.

> > 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.

Noted; we need to work on that so that we can depend on HAL 0.5.8.  :-)

Cheers,
Elijah