Re: [gentoo-science] lapack 3.0? (rkward)

[Honza Macháček]

On 26.02.2007 01:38, M. Edward (Ed) Borasky wrote:
> I'm a little curious about something ... does "rkward" actually require
> an external Lapack, or is this optional? The reason I ask is that R
> itself *contains* a copy of Lapack, and the R developers have deprecated
> linking against external Lapack libraries!

  I think I recall some discussion at the bugzilla to the point that all
multimedia packages that compile their own libraries instead of linking
to external ones should be hardmasked, allegedly for the sake of
maintainability. Moreover in my mailbox I've found an old discussion
(28. 8. 2006) of Freemat 2.0 and problems with its dependency on matio,
when accidentally I myself called to attention that Freemat sources
contained their own copy of the matio library, and Andrey G. Grozin
dismissed the option of using them rather fiercely, reasoning:

> This goes against modularity, *the* fundamental principle of any good
> Linux distribution.

  Anyway, lapack dependence in a frontend to an actual computation
package looks rather suspiciously. Having tried to remove the lapack
dependence from the rkward ebuild did not reveal anything, of course,
when I have lapack-atlas installed. So I grepped the rkward sources case
insensitively for lapack -- since it appears only as R_LAPACK_FLAG,
libRlapack.* and -lRlapack, I think the package really uses algebra
libraries only through R.
  I checked the rkward dependencies in its INSTALL file -- looks like
those in the ebuild (>=x11-libs/qt-3.3.4, >=kde-base/kdelibs-3.4.1) are
too restrictive, the INSTALL file says only ``KDE-libraries and headers
(>= 3.x)'' and ``Qt-libraries and headers (>= 3.x)''. On the other hand,
the rkward INSTALL file claims dependency on R shared library and PHP
comand line interface, so the ebuild probably should test whether PHP
has CLI installed (the R shared library is always installed by the R
ebuild). Unfortunately this is the point where my knowledge of Gentoo
portage reaches its limits, so I cannot try such modification to the ebuild.

  Experimenting, I tried to dispose of all the src_*() functions, but
then the ebuild failed to actually install any files to my system;
nevertheless src_unpack() probably is excessive. At least on my computer
the ebuild installed without it.

  With best regards
						Honza Macháèek

-- 
gentoo-science@g.o mailing list