From Fedora Project Wiki
(remove leftover comment)
m (Add trackers)
 
(One intermediate revision by the same user not shown)
Line 52: Line 52:
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
-->
-->
* Tracker bug: <will be assigned by the Wrangler>
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1792488 #1792488]
* Release notes tracker: <will be assigned by the Wrangler>
* Release notes tracker: [https://pagure.io/fedora-docs/release-notes/issue/438 #438]


== Detailed Description ==
== Detailed Description ==
Line 196: Line 196:
-->
-->


[[Category:ChangeReadyForFesco]]
[[Category:ChangeAcceptedF32]]
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->

Latest revision as of 17:29, 17 January 2020


Mono 6.6

Summary

Update the Mono stack in Fedora from 5.20 to 6.6. We need to do again a bootstrap build.

Owner

Current status

Detailed Description

Even between minor releases, we need to build Mono by doing a bootstrap. I have successfully built Mono 6.6 without bootstrap, once I have Mono 6.6 installed which was built with bootstrapping enabled.

I would like to request permission to make a one time exception of the rule for building mono 6.6.0-1 using monolite and the reference assemblies, later make mono depend again on itself and rebuild mono 6.6.0-2 using mono-6.6.0-1.

Steps for bootstrapping:

  • The Monolite binaries are included in the Mono tarball which is provided by upstream. See also http://www.mono-project.com/docs/advanced/monolite/
    • Monolite is a minimal binary distribution of mcs. This is the compiler that is able to build the rest of Mono.
  • The binary reference assemblies are included in the Mono tarball which is provided by upstream. The tarball also includes the sources of the reference assemblies, which are maintained here: https://github.com/dotnet/source-build
  • In the spec file, we usually delete all dlls and executables before the build section.
  • For the bootstrap, we would once keep the monolite binaries and some binary reference assemblies.
  • In the bootstrap, we rebuild the reference assemblies and include them in the mono-devel package, as well as the mono compiler.
  • After Mono has been built for all primary and secondary architectures, we enable the deletion of the binaries again in the spec file.


Benefit to Fedora

Fedora aims to showcase the latest in free and open source software - we should have the most recent release of Mono 6.x

Scope

  • Proposal owners:

Update mono spec and build in koji until it is ready. Members of the Mono SIG can rebuild their packages with Mono 6.6. Rebuild of all packages depending on Mono can happen during the regular mass rebuild.

  • Other developers: N/A (not a System Wide Change)
  • Policies and guidelines: N/A (not a System Wide Change)
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

N/A (not a System Wide Change)

How To Test

N/A (not a System Wide Change)

User Experience

Dependencies

N/A (not a System Wide Change)

This is not a system wide change, but only affects packages depending on Mono, and should be managed by the members of the Mono SIG.

Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change), Yes/No
  • Blocks product? product

Documentation

N/A (not a System Wide Change)

Release Notes