Re: what to do about dependencies?

[Olaf Till]

On Fri, Jan 06, 2012 at 11:36:20AM -0500, John W. Eaton wrote:
> People often complain that building Octave is too complicated.  The
> problem is usually that it is too hard to get dependencies installed,
> and we don't even have a complete statement of what dependencies are
> needed or where to get them.  One only finds out by running configure.
> 
> I've tried to help improve that situation slightly with the following
> patch to document the dependencies and where to find their sources:
> 
>   http://hg.savannah.gnu.org/hgweb/octave/rev/87f06b9990bb
> 
> I'm not pretending that this is perfect or complete, but it is a
> start.
> 
> For the future, I think we should consider including at least the
> required dependencies (GNU Readline, PCRE, BLAS+LAPACK (ATLAS?)) and
> all numerical library dependencies (ARPACK, FFTW3, GLPK, Qhull,
> QRUPDATE, and SuiteSparse) with Octave.  Then we could arrange for the
> configure script to automatically fall back to the included packages
> if these libraries are not already installed, or if there is some
> problem with them that would prevent them from being used.  There
> could also be a summary message from configure explaining that this is
> happening so that the user would have a chance to fix the system
> problems and run configure again instead of just using the included
> software.
> 
> I'm not sure whether we should consider including other libraries as
> well.  The cURL, HDF5, and zlib libraries might be fairly easy, but
> something like GraphicsMagick++ itself requires several more libraries
> and I don't think we want to attempt including everything down to the
> level of the C library (!).  But the list above would go a long way to
> avoiding the complaints we see about how hard it is to build Octave
> and dependencies.  At least running configure and make would work and
> build a copy of Octave that would run, though perhaps without graphics
> capabilities.
> 
> We could also have configure options to force the included libraries
> to be used instead of the system libraries.  That way we would be able
> to point to a set of package versions that are known to work.
> 
> I'm not proposing that we do this for the 3.6.0 release, but that we
> consider it for 3.8.0.
> 
> Comments?
> 
> jwe

Even people experienced in installing from source might sometimes fail
to notice these planned messages of configure as long as configure
succeeds. Especially since the planned behavior is not usual for source
packages (AFAIK) and so is not expected.

But I'd guess that the people you do this all for do not always see
all implications of this behavior, even after having read the
messages, and might mess up their system.

As you know it is mostly preferable to install a basic library from
the corresponding package of the distribution. If no such package
exists or its version is inadequate, there is sometimes the
possibility to get the needed version by compiling the source of the
package of a higher versioned distribution (as Unstable in Debian). If
you really need the to compile from tarball, but also have to install
the corresponding package of the distribution due to some dependency,
you possibly must take provisions that only Octave uses the package
from tarball, but the rest of the distribution uses the regular
package. I'm not sure I'm seeing all difficulties correctly, but there
surely are some decisions to take in such cases and the whole thing is
not so easy that it can be made automatically without looking at it.

So if one disregards the warnings of configure, which I guess will
happen not too seldom, one could mess up ones system.

What about just hosting some libraries which are difficult to get, or
whose versions are likely not contained in most distributions,
together with Octave and letting configure point out this? Then you do
help, but not with the danger that someone uses the intended help
unintentionally. But on the other hand this is not much different from
what you already did when pointing to the sources ...

Olaf