Re: external dependencies

["Elijah Newren" <newren gmail com>]

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.