Roadmap for Mono packages in Fedora ?

Honza Horak hhorak at
Tue Apr 14 06:27:33 UTC 2015

On 04/13/2015 10:56 AM, Jaroslav Reznik wrote:
> ----- Original Message -----
>> Not sure what you agreed, but I can imagine that I want in Fedora latest
>> Ruby on Rails and in Playground maintain its older (still supported)
>> releases (or vice versa).

The relevant discussions I mentioned are these:
(feel free to go through it to see what are the reasons)

Borrowing langdon's comment about where playground should have its place:

`copr is janky.. playground is "wants to grow up to be main, but not 
ready yet`

and as slavek reworded it:

`playground should be kind of "EPEL", for packages that are not or never 
will be in main fedora; for many conflicting repos, we already have copr 

That makes great sense to me.

> This leads to the question I've raised a long time ago - do we want one
> fits them all "repository" or more tailored repositories?
> And that time we agreed - let's start with one Playground repository,
> more limited in what can be there and if it works, let's take a look
> on more. And I think it still make sense to start with smaller steps.
> Supplementary, Playground, Fresh, Oldies repos...

Right. However, for example for newer/older versions of packages that 
are in base fedora, it doesn't make much sense to have them in one big 
repo, since for enabling one we would need to enable all of them. For 
those the concept of isolated coprs seems to be more beneficial. But we 
can definitely work on making even those packages more visible and 
better tested than just pure coprs.


>> And no, doing rename reviews etc to maintain older releases in Fedora
>> does not scale.
>> Vít
>> Dne 10.4.2015 v 17:30 Honza Horak napsal(a):
>>> Haven't we agreed two weeks ago that playground packages shouldn't
>>> conflict with base system? that means new versions won't be in
>>> playground, for those pure copr should be enough.. the playground is
>>> supposed to be more for packages that cannot be in fedora due
>>> packaging guidelines issues (bundling is great example). At least this
>>> what I got from the meeting two weeks ago..
>>> Honza
>>> On 04/10/2015 02:46 PM, White, Langdon wrote:
>>>> Seems like a great oppty for a playground example... think envs and
>>>> stacks could follow up on this and help these guys get the existing mono
>>>> build they have in to playground while pkg reviews and the like take
>>>> place?
>>>> langdon
>>>> ---------- Forwarded message ----------
>>>> From: "Timotheus Pokorra" <timotheus.pokorra at
>>>> <mailto:timotheus.pokorra at>>
>>>> Date: Apr 10, 2015 2:38 AM
>>>> Subject: Re: Roadmap for Mono packages in Fedora ?
>>>> To: "Development discussions related to Fedora"
>>>> <devel at <mailto:devel at>>
>>>> Cc:
>>>> Hello,
>>>> this is my first post to this list. My name is Timotheus Pokorra, I am
>>>> from Germany, and I am also interested to get an uptodate version of
>>>> Mono into Fedora and later into CentOS or Epel.
>>>> I am developing and deploying OpenPetra, an administration software
>>>> under GPL for charities and mission organisations, on CentOS.
>>>> I am maintaining Mono packages on OBS for various linux distributions:
>>>> Obviously it is quite easy because there are no rules to follow.
>>>> I understand that a distribution like Fedora needs packaging rules,
>>>> and the rules have a good reason.
>>>>   > I am not working on this currently. Some one should inform upstream
>>>>   > that it doesn't build for GCC 5 / C++ 11.
>>>> It seems that Mono 4.0 Alpha1 builds fine on Rawhide:
>>>> I have added a comment to:
>>>> IMHO I think we should focus on getting Mono 4.0 into Fedora
>>>> (according to the "First" foundation of Fedora...)
>>>> All the best,
>>>>     Timotheus
>>>> --
>>>> devel mailing list
>>>> devel at <mailto:devel at>
>>>> Fedora Code of Conduct:
>>> _______________________________________________
>>> env-and-stacks mailing list
>>> env-and-stacks at
>> _______________________________________________
>> env-and-stacks mailing list
>> env-and-stacks at
> _______________________________________________
> env-and-stacks mailing list
> env-and-stacks at

More information about the env-and-stacks mailing list