Hello,
just to let you know:
We now have Mono 4.3.2 in Rawhide. It is called Cycle 7 Alpha. In the
#mono IRC I was told that it should have been named Mono 4.4, and the
next Alpha release will be from the Mono 4.4 branch.
Here are the first drafts of the release notes:
http://www.mono-project.com/docs/about-mono/releases/4.4.0/
One bigger change is this: "Our build system has been reconfigured to
become a 4.x setup, as opposed to 4.5 only and it’s now tracking .NET
4.6.1 APIs."
It seems the reference assemblies are taking a more prominent place.
We are not using them for Fedora. So we can only target the latest
4.6.1 APIs. I have added symlinks for 4.0 and 4.5 to point at the
latest API. That way we don't need to change the TargetFramework in
the csproj files of all the packages depending on Mono in Fedora.
See the changes here:
http://pkgs.fedoraproject.org/cgit/rpms/mono.git/tree/mono-4.0.0-ignore-r...
I also had quite an issue with mscorlib and other dlls not included in
the rpm package.
I am glad that I was still able to run koji untag-pkg as suggested in
fedora-devel.
So in the future, we need to build Mono packages first in copr, and
then see if we can still compile other packages depending on Mono, and
Mono itself with that new version.
The reason for the problems in this release is that less assemblies
are in the GAC by default. Even not System.IO.dll. I don't fully
understand that, but I guess it works. We just need to make sure that
mono-find-provides still picks those dlls up even though they are not
in the GAC. I have fixed that here:
http://pkgs.fedoraproject.org/cgit/rpms/mono.git/tree/mono-4.3.2-find-pro...
The Xamarin rpms have manual mention of each Provide, which we don't
want in our spec file:
https://github.com/mono/linux-packaging-mono/blob/centos/mono-core.spec
We are not able to build MonoDevelop 6 Alpha, because there are no
tarballs released yet.
Please let me know if you find any issues with Mono in Rawhide.
Have a nice weekend,
Timotheus