Yum repo

[Dave Curylo]

There doesn't appear to be a yum repository maintained for mono anymore.  I
would like to help contribute a repository as my corporation supports mono
applications and has a vested interest in ensuring mono is available to
Fedora, RHEL, and CentOS systems.  I have requested assistance in obtaining
mono RPM specs via the mono mailing lists, and my company would be willing
to provide hosting, compute, and storage resources for building and
packaging mono for the repository.  Per their recommendation, I am hoping
to contribute this to EPEL and hope that you can provide guidance in
creating the repository and maintaining the RPM spec files that I have, as
yet, been unable to find.

What are the next steps to a) getting the RPM spec files to do mono
packaging and b) creating a yum repository suitable for EPEL to serve the
mono packages?

Best regards.

[Ismael Olea]

On Fri, Jul 6, 2012 at 9:31 PM, Dave Curylo <curylod(a)asme.org&gt; wrote:

What are the next steps to a) getting the RPM spec files to do mono
>  packaging and b) creating a yum repository suitable for EPEL to serve
> the
>  mono packages?
>  
Dave: EPEL current offers mono for RHEL 5 and 6

ie:
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2011-3635/mono-2.4.3....

and all sources are available:

http://pkgs.fedoraproject.org/gitweb/?p=mono.git

of course there are more mono packages but accessible using the same webapps

-- 

Ismael Olea

http://olea.org/diario/

[Hin-Tak Leung]

--- On Fri, 6/7/12, Ismael Olea <ismael(a)olea.org&gt; wrote:

From: Ismael Olea <ismael(a)olea.org&gt;
Subject: Re: Yum repo
To: mono(a)lists.fedoraproject.org
Date: Friday, 6 July, 2012, 20:37



On Fri, Jul 6, 2012 at 9:31 PM, Dave Curylo <curylod(a)asme.org&gt; wrote:


What are the next steps to a) getting the RPM spec files to do mono packaging and b)
creating a yum repository suitable for EPEL to serve the mono packages?
Dave: EPEL current offers mono for RHEL 5 and 6


ie: https://admin.fedoraproject.org/updates/FEDORA-EPEL-2011-3635/mono-2....


and all sources are available: 
http://pkgs.fedoraproject.org/gitweb/?p=mono.git
of course there are more mono packages but accessible using the same webapps

 -- 

Ismael OleaBesides Ismael's comment, the spec files, and other fedora specific patches
can be got from git clone'ing
git://pkgs.fedoraproject.org/mono.git
(this should be obvious from the http pkg.fedoraproject link above)
I should also point out that you can grab the source rpms from
http://koji.fedoraproject.org/
. While it is true that RHEL and other redhat linux's shipped mono tends to be
out-of-date - for obvious reasons, since you will need to rebuild everything that depends
on mono, which is a lot! - fc18's - or rawhide's - is always up to date, and I
have had no problems grabbing an fc18 srpm and doing rpm --rebuild on fc17/fc16's, and
occasionally get a few more pdated dependent packages when it does complains about
dependencies.YMMV. 
OTOH, if you do start to ship mono 2.10.8, or godforbid mono 2.11.2 for RHEL, you will
have to provide the whole mono-dependent stack, which is not a small undertaking. Be
warned...

[Dave Curylo]

On Fri, Jul 6, 2012 at 6:05 PM, Hin-Tak Leung
<htl10(a)users.sourceforge.net&gt;wrote:

>  --- On *Fri, 6/7/12, Ismael Olea <ismael(a)olea.org&gt;* wrote:
>
>
>  From: Ismael Olea <ismael(a)olea.org&gt;
>  Subject: Re: Yum repo
>  To: mono(a)lists.fedoraproject.org
>  Date: Friday, 6 July, 2012, 20:37
>
>
>
>
>  On Fri, Jul 6, 2012 at 9:31 PM, Dave Curylo
> <[e-mail]<http://mc/compose?to=[e-mail]>
>  > wrote:
>
>  What are the next steps to a) getting the RPM spec files to do mono
>  packaging and b) creating a yum repository suitable for EPEL to serve the
>  mono packages?
>
>
>  Dave: EPEL current offers mono for RHEL 5 and 6
>
>  ie:
>
> https://admin.fedoraproject.org/updates/FEDORA-EPEL-2011-3635/mono-2.4.3....
>
>  and all sources are available:
>
>  http://pkgs.fedoraproject.org/gitweb/?p=mono.git
>
>  of course there are more mono packages but accessible using the same
>  webapps
>
>  --
>
>  Ismael Olea
>
>  Besides Ismael's comment, the spec files, and other fedora specific
>  patches can be got from git clone'ing
>
>  git://pkgs.fedoraproject.org/mono.git
>
>  (this should be obvious from the http pkg.fedoraproject link above)
>
>  I should also point out that you can grab the source rpms from
>  http://koji.fedoraproject.org/
>
>  . While it is true that RHEL and other redhat linux's shipped mono tends
>  to be out-of-date - for obvious reasons, since you will need to rebuild
>  everything that depends on mono, which is a lot! - fc18's - or rawhide's -
>  is always up to date, and I have had no problems grabbing an fc18 srpm and
>  doing rpm --rebuild on fc17/fc16's, and occasionally get a few more pdated
>  dependent packages when it does complains about dependencies.YMMV.
>  
Many other software packages offer alternative repositories for using newer
builds on RHEL and CentOS - RabbitMQ and MongoDB, for example - so my hope
is that there would be a similar repository for mono.  I can understand
that if other packages on the same system depend on mono, they would be
affected, but my software is running alone within a virtual appliance so I
have complete control over the software being installed.  Thank you for
pointing out the fc18 repository and if you've had luck with that, I will
give that a go.


>  OTOH, if you do start to ship mono 2.10.8, or godforbid mono 2.11.2
> for
>  RHEL, you will have to provide the whole mono-dependent stack, which is not
>  a small undertaking. Be warned...
>
>  
It seems that the whole mono dependent stack already ships in the standard
RHEL repos, as I can build mono 2.10.8 using this script, which pulls all
it's dependencies from the standard repositories:

https://github.com/nathanb/iws-snippets/blob/master/mono-install-scripts/...

My software builds, runs, and tests as expected, so I believe 2.10.8 to
work on CentOS 6, but I'd prefer not to require mono be built from source
in order to deploy my software package.  As such, I'm on the hunt for a
repo, or, if I have to create my own, I want to follow the process to make
it available for others as more users of the repo will improve the quality.

Thank you both for your guidance.

[Hin-Tak Leung]

--- On Sat, 7/7/12, Dave Curylo <curylod(a)asme.org&gt; wrote:

Many other software packages offer alternative repositories for using newer builds on RHEL
and CentOS - RabbitMQ and MongoDB, for example - so my hope is that there would be a
similar repository for mono.  I can understand that if other packages on the same system
depend on mono, they would be affected, but my software is running alone within a virtual
appliance so I have complete control over the software being installed.  Thank you for
pointing out the fc18 repository and if you've had luck with that, I will give that a
go.

 

OTOH, if you do start to ship mono 2.10.8, or godforbid mono 2.11.2 for RHEL, you will
have to provide the whole mono-dependent stack, which is not a small undertaking. Be
warned...   



It seems that the whole mono dependent stack already ships in the standard RHEL repos, as
I can build mono 2.10.8 using this script, which pulls all it's dependencies from the
standard repositories:


https://github.com/nathanb/iws-snippets/blob/master/mono-install-scripts/...


My software builds, runs, and tests as expected, so I believe 2.10.8 to work on CentOS 6,
but I'd prefer not to require mono be built from source in order to deploy my software
package.  As such, I'm on the hunt for a repo, or, if I have to create my own, I want
to follow the process to make it available for others as more users of the repo will
improve the quality.


Thank you both for your guidance.
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. 
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.

[Dave Curylo]

On Fri, Jul 6, 2012 at 8:17 PM, Hin-Tak Leung
<htl10(a)users.sourceforge.net&gt;wrote:

>  --- On *Sat, 7/7/12, Dave Curylo <curylod(a)asme.org&gt;* 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?

[Hin-Tak Leung]

--- On Mon, 9/7/12, Dave Curylo <curylod(a)asme.org&gt; wrote:

On Fri, Jul 6, 2012 at 8:17 PM, Hin-Tak Leung <htl10(a)users.sourceforge.net&gt; wrote:


--- On Sat, 7/7/12, Dave Curylo <curylod(a)asme.org&gt; 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.

[Dave Curylo]

On Mon, Jul 9, 2012 at 1:28 AM, Hin-Tak Leung
<htl10(a)users.sourceforge.net&gt;wrote:

>  You seems to not understand what I was saying. I am not talking about what
>  latest mono depends on, but what depends on mono.
>
>  
I get what you're saying. As I said before, I understand that if other
packages on the same system depend on mono, they would be affected, but my
software is running alone within a virtual appliance so I have complete
control over the software being installed. My concerns here are merely with
the deployment of the mono 2.10 framework for use by my software. I'm not
interested in replacing the system level libraries that provide RHEL and
CentOS with its enterprise grade stability - just a framework that sits on
top of that stable system.  It's a matter of being able to choose the
software framework(s) I wish to run on the system that I control.

> From this discussion, it sounds like EPEL is the wrong place for
> shipping a 
recent version of mono given the stated goal of "EPEL packages are
usually
based on their Fedora counterparts and will never conflict with or replace
packages in the base Enterprise Linux distributions."  If you have a
recommendation of a repo that ships a recent version or would be willing to
include one if there was a package maintainer, please let me know.

Thanks again for your help.

[Hin-Tak Leung]

--- On Mon, 9/7/12, Dave Curylo <curylod(a)asme.org&gt; wrote:

From: Dave Curylo <curylod(a)asme.org&gt;
Subject: Re: Yum repo
To: htl10(a)users.sourceforge.net
Cc: "mono" <mono(a)lists.fedoraproject.org&gt;
Date: Monday, 9 July, 2012, 12:54


On Mon, Jul 9, 2012 at 1:28 AM, Hin-Tak Leung <htl10(a)users.sourceforge.net&gt; wrote:



You seems to not understand what I was saying. I am not talking about what latest mono
depends on, but what depends on mono. 



I get what you're saying. As I said before, I understand that if other packages on the
same system depend on mono, they would be affected, but my software is running alone
within a virtual appliance so I have complete control over the software being installed.
My concerns here are merely with the deployment of the mono 2.10 framework for use by my
software. I'm not interested in replacing the system level libraries that provide RHEL
and CentOS with its enterprise grade stability - just a framework that sits on top of that
stable system.  It's a matter of being able to choose the software framework(s) I wish
to run on the system that I control.


> From this discussion, it sounds like EPEL is the wrong place for
> shipping a recent version of mono given the stated goal of "EPEL packages are usually
> based on their Fedora counterparts and will never conflict with or replace packages in the
> base Enterprise Linux distributions."  If you have a recommendation of a repo that
> ships a recent version or would be willing to include one if there was a package
> maintainer, please let me know. 

Thanks again for your help.
Whichever you choose/approach is, I think there is some maintainence work-load involved if
you want to keep both the system up to date as well as having the latest mono. If you
choose to do rpm --rebuild a rawhide rpm to replace those in a earlier distro (be is EPEL
or current fedora), you run the risk of eventually having to resolve conflicts; it may be
simplier to ship your virtual appliance as a completely stock/up-to-date EPEL/fedora
without any mono related pieces, and have an up-to-date mono installed under /usr/local
and outside of the package management system. (and you would want to ship as minimal a
system as possible in either case).