Re: external dependencies; trolling for more feedback, pushing to make it official ; -)

["James Henstridge" <james jamesh id au>]

On 22/09/06, David Zeuthen <david fubar dk> wrote:
> On Thu, 2006-09-21 at 23:09 -0400, Joseph E. Sacco, Ph.D. wrote:
> > GARNOME does not roll or maintain source tarballs for developers.
> >
> > I do not know of any stable Linux distro that currently offers a new
> > enough version of udev that provides libvolume_id.  At some point,
> > hopefully in the near future, this will change. Until that time, a
> > source tarball for libvolume_id will need to be made available in order
> > to build HAL-0.5.8.x.
>
> There is. It's called udev. You can download it from here
>
>  http://kernel.org/pub/linux/utils/kernel/hotplug/
>
> It's not really my fault GARNOME can't handle this. Sorry. I'm not going
> to carry extremely security sensitive code (that introduces attack
> vectors like root exploits via USB keys) with all the fun that entails
> like coordinated releases, embargo fun and what not, just because
> GARNOME lacks a feature.
>
> I hope you realize what a silly thing you are asking me to do.
>
> Release team: Please apply cluebat. Thanks.

Given that a lot of this thread has been about making things easier to
build, I can understand Joseph's complaints.  While most of the stack
people build for testing Gnome use roughly the same build
infrastructure, udev has it's own setup which doesn't seem as well
suited to building in a non-default prefix.

Here are some notes on trying to do this:

1. it doesn't use the standard autoconf setup, but that isn't too
surprising since it isn't intended to be portable.

2. Running "make" doesn't appear to build libvolume_id -- just the
basic udev utilities.  Consulting the README file indicates that I was
really meant to run "make EXTRAS=extras/volume_id".

3. Using the "make install-bin" target attempts to delete a bunch of
files under /dev and restart a system daemon (it ignores the errors
when this fails due to me not being root -- I wouldn't want to include
this sort of thing in a build script that other people will run).

4. You can set the prefix variable when installing things to
$prefix/usr/lib, $prefix/usr/bin, etc.  It looks like setting
includedir and usrlibdir and a few others might do the right thing
though.  The README file doesn't really mention any of this, so it
isn't clear that it'd continue to work with new versions, or might
need new/different variables.

Now given that I don't really care about the rest of udev here, it
might be easier to just build in "extras/volume_id/lib", but the
Makefile in that directory doesn't seem complete: relying on a bunch
of variables defined in the calling Makefile (from an initial look, Q,
E and RANLIB at a minimum).  The installation issues are the same for
this method of building.

So I can understand wanting to either rely on a distro installed
libvolume_id, or rely on some package other than udev to provide the
library (which is effectively what Joseph is doing by using the older
hal).

James.