--- On Mon, 9/7/12, Dave Curylo <curylod@asme.org> wrote:

On Fri, Jul 6, 2012 at 8:17 PM, Hin-Tak Leung <htl10@users.sourceforge.net> wrote:
--- On Sat, 7/7/12, Dave Curylo <curylod@asme.org> wrote:
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?


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.