#2105 F31 Change: Mono 5
Closed: Accepted 4 years ago by zbyszek. Opened 4 years ago by bcotton.

Update the Mono stack in Fedora from 4.8 to 5.*

Maybe this is a bad question to ask, but why aren't we doing this in Fedora 30?

Mono 4.8 is not supported by upstream, and we even have a broken architecture as it stands. The effort to upgrade Mono to v5 in Fedora 30 doesn't look terribly substantial, and it's not even part of any delivered media (ISOs, etc.). So the risk is quite low, and it would only benefit us to finally just bump everything to a supported Mono version, especially now that the DotNet SIG has figured out how to rebootstrap Mono in Fedora.

If the Mono stack is actually broken in Fedora 30, I'd be willing to entertain such a change. However, if it's working and just unsupported upstream, I'd be hesitant to do it so late. What architecture is "broken" and how?

@sgallagh ppc64le has been FTBFS for a while now, as I understand it. Mono 5 would resolve this problem.

@sgallagh I'm also concerned about security fixes and other issues. Mono 5 was released in 2017, and Mono 4 releases stopped after Mono 5 was released.

It was "kind of" okay that we had Mono 4 when we couldn't figure out how to rebootstrap to Mono 5. But that problem has been solved upstream, and the latest releases of Mono 5 can be bootstrapped and built from source in Fedora.

@tpokorra Would you like us to consider this proposal for late inclusion in Fedora 30?

I'm not going to vote either way without hearing from the person doing the work.

@tpokorra For what it's worth, I can try to help with this if you need the manpower. I'm a provenpackager, so I can assist with rebuilds.

@sgallagh, @ngompa : I would be happy if it would be allowed for Fedora 30.

Perhaps we don't need much rebuilds after all.

I am worried a bit on the impact we could have on a certain third-party software, like gog installer for example. Mono is not completely isolated thing, it has certain public-facing features.

I guess we don't have a formal pre-release testing procedure for that anyway, so it should be business as usual, with maintainer and SIG to manage that. Thus, generally I agree.

But shouldn't we at least announce the intent for F30 on a mailing list and see if someone comes up with smth before making a final decision?

@bookwar We are increasingly in a situation where stuff doesn't work on Mono 4 but works on Mono 5. And Mono 5 has good backwards compatibility to Mono 4 applications (which is probably why they straight up discontinued Mono 4 maintenance).

I am +1 for making this a late change to Fedora 30. It sounds unlikely that the upgrade can cause more problems than we already have. In the absolute worst-case scenario, if this breaks a third-party irrevocably, they are welcome to join the package maintainers and produce a Mono 4 (non-default) module stream.

Are we seriously expecting a third party to "join modularity" when even current Fedora packagers are kinda not into it, except a very small group of them?

Are we seriously expecting a third party to "join modularity" when even current Fedora packagers are kinda not into it, except a very small group of them?

No, I literally used the phrase "In the absolute worst-case scenario". I'm not sure how that could be construed as any kind of expectation. I mean, if there's some crazy situation out there where fixing their software to run on a supported and mostly-backwards-compatible version of Mono is infeasible, they have this option if they want to take it.

It was a roundabout way of saying that, unlike historically, there remains recourse for them even in that situation.

Thanks for explaining that a bit better. I guess technically they do have that option.

I've announced this on devel (and devel-announce): https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/R5V6LEZVDG4HNE2YQC6PZ5MRLCAJBFKN/

I don't feel confident enough to +1 this for Fedora 30 before others can provide their data points / arguments / etc.

With my alt-arch hat on I support the inclusion of Mono5 in F-30 as it will bring consistency and alt-arch fixes for Mono itself.

I am personally OK with it given the state of Mono 4, but I too would like to see some discussion on devel list before voting.

I would agree with the sentiment of adding to f30 so long as it improves the consistency.

I'd like to see mono 5 as an alternative package in F30 in the late future, and then become the default in F31 (and mono 4 as alternative, if needed).

@aflyhorse Why? Mono 4 is dead upstream, no one is taking care of it. No bug fixes, no security fixes, nothing. Mono 5 is pretty much backwards compatible to Mono 4 (applications for Mono 4 are expected to run on Mono 5).

Is there a compelling reason for supporting Mono 4 in the distribution as a supported package at all? Is anyone able to actively maintain it with fixes? Support the architectures that Fedora has?

@ngompa As a AIW member I incline towards preservation of things that might be useful to someone, for a while.

Anyway Mono 4 has already been left as-is in Fedora in several dists. It won't hurt to left it parallel in F31 for another half year, and make the transition more smoothly. Users can test his workflow on Mono 5 and fire compatibility reports on it, and revert to his old working Mono if needed. This gives the community to amend problems and won't force the user to seek dist downgrade solution, third-part repos, or another Linux redistribution.

@aflyhorse The only reason Mono 5 wasn't introduced in Fedora 28 was because we couldn't build from bootstrap to rebuild from source. That issue was fixed. During the course of Fedora 30 development, the Mono 4 runtime failed to build for ppc64le. That means a whole architecture lost support for any programs using .NET languages (like C#) now. Upgrading to Mono 5 resolves this issue, and even makes it possible for us to upgrade libraries with new versions as needed. There are already libraries that the DotNet/Mono SIGs want to update to that will not build without upgrading to Mono 5, including important libraries like sharpziplib.

As @sgallagh points out, if you really want Mono 4, you can elect to build a module for it. And the historical packaging is preserved in Git, so people can get to it whenever they need to. Alternatively, COPR is a fine solution for packages where things like vulnerabilities or other bugs are not the concern of the distribution.

I didn't really want Mono 4 and don't want to argue with you on that. Please note that I "
Edited an hour ago" and added "if needed" to represent weak suggestion.

And I agree COPR is a fine solution and I keep old jpeg libraries on it to provide compatibility workarounds.

In the end, I do not think it is worth it to keep Mono 4 in the distribution for another 13 to 15 months (remember, if we keep it in F30, it has to stick around for the entirety of F30's life, which is N+2 releases) when we can just fix this now for Fedora 30. Let's stem the bleeding.

@tpokorra If we vote and decide yes on Monday 25, when you expect it to land in F30?

Looking at https://fedoraproject.org/wiki/Releases/30/Schedule before Beta is out of questions, right after Beta?

@bookwar: I have the spec and patches ready, so I could push the package immediately after the beta release.

You can do the builds now. You can even create an update in bodhi, and it can go in after the beta freeze is lifted. (This approach could create a problem where a rebuild of one of the packages is needed to fix a blocker bug, but since those are leaf packages that are not in the critical path, I think that's unlikely to be needed.).

However if this is not approved, it would need to unpushed, reverted in git, maybe even epoch bump...

Metadata Update from @bookwar:
- Issue tagged with: meeting

4 years ago

Could we get mono 5 into rawhide now, I do not see any scratch builds in koji and I worry about non x86 support. Knowing that its in rawhide and working would go a long way to saying it is okay for Fedora 30.

I count (+5,0,-0) for this proposal in Fedora 31. I will proceed with it as approved there while the F30 discussion continues.

I am +1 for both F31 and F30

I have now worked on the package for Rawhide.
After some modifications to the spec file, the scratch bootstrap build worked fine for most architectures, only s390x is just hanging at a certain point: https://koji.fedoraproject.org/koji/taskinfo?taskID=33684651

I will commit the spec file and patches tonight, and start another scratch build.

I see a segfault in mini/mono-sgen when rebuilding mono-5.18.1-1.fc31.src.rpm locally on F-28 s390x. But that looks fixable.

And with F-30 it hangs in futex() call, called from dlopen(). More details/bugs will follow.

+1 for both f30/f31 unless serious issues are found.

This was discussed in today's FESCo meeting:
AGREED: The Change is approved for F31. It is also approved for F30, as long as the builds can be done and submitted as an update no later than March 31. If this isn't possible, F30 should keep the previous version. (+7, 0, 0)

Metadata Update from @zbyszek:
- Issue close_status updated to: Accepted
- Issue status updated to: Closed (was: Open)

4 years ago

Metadata Update from @zbyszek:
- Issue untagged with: meeting

4 years ago

Nothing should block the F-30 build as Rawhide/F-31 one succeeded on all arches a moment ago (https://koji.fedoraproject.org/koji/buildinfo?buildID=1239640).

Login to comment on this ticket.