--- On Mon, 9/7/12, Dave Curylo <curylod(a)asme.org> wrote:
On Fri, Jul 6, 2012 at 8:17 PM, Hin-Tak Leung <htl10(a)users.sourceforge.net> wrote:
--- On Sat, 7/7/12, Dave Curylo <curylod(a)asme.org> wrote:
https://github.com/nathanb/iws-snippets/blob/master/mono-install-scripts/...
I am aware of that script - but you will find that "yum check", for example,
will not be happy, especially on a fully loaded RHEL system. Given that RHEL seems to
still be with mono 2.4.x, while fc18 has mono 2.10.8, and 2.11.2 is being tested and
2.12.0 is soon to be out from upstream.
I'd prefer not to use that script at all; I was just pointing out that mono 2.10.8
seems to have no dependencies beyond what already exists in the RHEL / CentOS 6 yum
repositories.
So what you are offering, can't quite apply generally to the usual RHEL systems.
This has the problem that if you go that way, some RHEL packages will have problem
upgrading through the official channels afterwards. I have been there before, though the
difference between the fedora core releases is much less compared to the difference
between RHEL and fc18/rawhide.
So no script, back to using RPM's from a yum repo, didn't this all work just as
recently as mono 2.10.2 using the repository provided by Novell?
http://wiki.visualwebgui.com/pages/index.php/Deploying_to_Mono_-_Install_...
That repo is gone for obvious reasons, but I don't see why not to stand up another
similar repository with 2.10.x for those that need a recent mono build on their RHEL /
CentOS systems. Are you saying this can't be done or would otherwise be a bad idea for
creating conflicts?You seems to not understand what I was saying. I am not talking about
what latest mono depends on, but what depends on mono. For example, on my current system,
$rpm -q --whatrequires mono-core |grep -v '2.10.8.1' | wc -l
11
i.e. 11 packages depends on mono-core and is not part of the set of mono packages. So
obvious none of them explicitly depend on a particular mono version (or I would have taken
them off and remove them). And that's just counting dependence on mono-core, not the
other part of mono packages. e.g. banshee requires and depends on a lot of mono's, but
not mono-core itself.
Some of that 11, like avahi-sharp, if it were to explicitly depend on a particular mono
version, would also lock most of avahi from being upgraded, and by extension, most of
dbus, and therefore most of the desktop.
What this boils down to is that if you were to put a newer mono package on your system
than redhat shipped, you would either have to minimize your mono dependency (i.e. remove
most things that depends on mono, as they would depend on the older version provided by
redhat), or you have to provide upgraded versions of the entire software stack that
depends n mono.
The former routine is not suitable one systems of general use (which means you do it to
your own system, but what you do will not be generally useful to others), while the latter
is a lot of work.