[Mono-list] Dependency issues with 1.1.13

Tony G s7oawcn02 at sneakemail.com
Thu Mar 16 13:46:58 EST 2006

Re-sending, it looks like my response didn't hit the list.

Shawn Vose wrote:
> I dont know if anyone has answered you already. RPM can be a bugger
> some times. This is what I have done in the past. First find out what
> is installed.
> rpm -qa | grep mono
> This should return a list of mono packages installed. The U option is
> indicating that you already have the package installed. If you already
> have an old copy laying around you might want to uninstall. That is a
> book in itself just because you have created many dependencies, so
> uninstall one at a time but this isnt necessary.

I used the U option because that's what the install page suggested.
Which BTW, is there only one page on the internet with info about
installing Mono from RPM?  Please point me to TFM on installation so I can
R it. :)  I know there are pages on installing from source - is that the
way to get around this dependency/versioning issue?  Since I'm not
upgrading this brand new Linux install (CentOS4.2), I switched to "rpm
-ivh".  I did check "rpm -qa" and there are no mono components installed.

> The reason you are getting these messages is because there is a
> circular dependency.

In this case it's not circular, just a chain of dependencies which may
require me to uninstall stuff that's working.  Again, the short of it is
that Mono is using libsqlite.so.0 from SQLite 2.8 which has now been
updated to libsqlite3.so.0 in SQLite 3.2 - and this 3.2 version is what's
installed via Yum and other updates.  It might be an easy thing to
recompile Mono with the newer version, I just don't know how.  As you see,
I'm daring enough to use RPM rather than an installer, but the last time I
tried to install Mono from source I was in the same dependency Hell that
I'm finding now.  I'm concerned that if I try to use the convenient
installer it's just going to abort with the same versioning issue after
having installed some of the packages, and then I might as well just
reinstall my Linux box - which is pretty much the reason I gave up on Mono
the first time.  Maybe I should try to do this via Yum?  I expect the same
issues though.

> Just rpm -Uvh every.single.rpm as one long ass
> command and let rpm figure out which one to install.
> for example
> rpm -Uvh mono-basic.rpm mono-core.rpm sqllite.rpm etc..

Isn't using all of the package names in a long line the same as using

(From an off-list e-mail exchange)
Shawn Vose wrote:
> so the sql lite is already installed for some other package?

Yes, I checked the dependencies and SQLite is installed with python which
is needed for some Gnome apps.  They're all dependent and trying to
uninstall will unravel a stream of packages.

If the next version of Mono can be built with SQLite 3.2 then this one
issue is fixed but I am guessing that this issue will constantly exist, as
we can't expect Mono developers to patch up to the very latest libs every
time they do a build.

My real question for anyone out there is how can we install of the required
libraries for Mono into a distro which already has libraries, and avoid the
versioning issues?  Can't we apply a different configure prefix to all
required packages so that we load somewhere else?  Am I missing something
basic here?  I have to think this is a problem that everyone who uses Linux
experiences on a daily basis, do I need to write C code and compile from
source to use this OS or this package?  And of course the other issue is -
once we install Mono does that mean we can't use all kinds of other
packages?  Man, does Linux need a GAC!

> Hope this helps and keep the faith. The joy of linux is just this, you
> always have the ability to really dig into it and learn something.

I'm really willing to learn how this works and document the process so that
others who follow will have a clue, but I don't want to bang my head
against insurmountable issues, nor do I think it's realistic to expect
people to completely uninstall some packages just to install others.


More information about the Mono-list mailing list