[El] Missing dependencies
mbaudier at argeo.org
Tue Aug 31 12:32:23 EDT 2010
thanks for this!
> about the same 75% functionality that the elgis packages offer: QGIS
> with no python support (a big limitation)
I do agree that this is a big limitation.
QGIS is a very actively developed product and a lot of innovation
happens at the Python plugins level, with third-party repositories,
> GRASS still without the digitizer and without nviz (a minor annoyance).
Just an idea: did you try whether it is working when using the TCL/Tk interface?
(run 'grass64 -tcltk' from the command line)
I could open File > 3D Rendering > NVIZ
but I don't know whether it is actually working since I'm not familiar
with this tool (neither with the digitizer, that I did not actually
It would be good to know whether there is a workaround or not.
Anyhow, I updated the wiki so that this limitation is listed.
> Trying QGIS, I first install the epel python26 packages, and using some
> ugly hacks I managed to get QGIS 1.5 compiled and working, but I still
> get a mismatch between python2.6 and the version of sip on CentOS, so
Two weeks ago I actually tried to rebuild (locally) the SIP and PyQt4
packages so that they use python26.
I could hack the spec files to a certain extent so that they pickup
this version of Python, but it failed, probably because the generated
binaries are not deployed at the proper place (I just realized that
when looking at your symbolic links).
According to your analysis, if:
- we could succeed in having SIP and PyQt4 properly integrated with
python26 instead of the default python
- we integrate your steps in the spec file
then, we would have a chance (we actually built the SIP and PyQt4
packages in the first place only in order to build and package QGIS)
It encourages me to have a look at this again when I'm back in the
office in two weeks time (I kept the modified spec files on my local
> and after opening the source tarball, I changed the Makefile:
isn't there a makefile under gui/wxpython/ (or gui/) that you should
modify instead of the main makefile? (just an idea, I don't have the
> Bottom line, as you said, we should wait for CentOS 6...
Is it so sure?
It will take a while after CentOS 6 is released before the entire
ecosystem (third party repos, forums, mailing-list, etc.) slowly
upgrades, and also before the OS reaches its praised stability.
As for myself, I'm not sure that I will upgrade all my desktops right
away, since for the most part they "just work fine" (which is the main
motivation of many EL users I guess).
I suggest that we:
- keep trying on CentOS 5 with not-so-high priority
- focus on having soon a modern and complete set of packages for CentOS 6
- do a poll and discuss this via the mailing-list after CentOS 6 is
out and people are making their mind about their update path
Thanks a lot for your help,
More information about the el