[mono-packagers] binaries in tarball

[Jo Shields]

On 10/04/15 10:08, Timotheus Pokorra wrote:
> Hello Jo,
>
> First I want to thank you and Xamarin for providing uptodate Mono
> packages for various Linux distributions.
>
> But as it has been stated on the Mono mailing list before [1], the end
> goal is to have uptodate Mono packages provided by the Linux
> distributions themselves.

This is still true, it'd definitely best for everyone if distributions
can offer up-to-date packages themselves - relationships between
distributions and upstreams are always best served if they're 2-way.

> I am trying to help to get a newer version of Mono into Fedora.
> I don't have so much experience with packaging like yourself, so I
> would like to ask for some advice.

Hooray, it's been rather quiet on the Fedora front for a while. Remember
to consider #mono on GIMPnet for discussion with other people into this
packaging stuff.

> According to the Fedora rules [2] and [3], the packages must build
> from source completely.
> I think this is the same for Debian.
> There are many dlls in the tarball, in
> mono-4.0.0/external/binary-reference-assemblies/v4.0
>
> I have checked the latest version that you built for Debian:
> https://packages.debian.org/source/testing/mono
> I have learned that you create your own tarball: eg mono_3.2.8+dfsg.orig.tar.gz
> This happens in the debian/rules file:
> find $(TARBALL_DIR) -name "*.dll" -not -path
> "$(TARBALL_DIR)/mcs/class/lib/monolite/*" -print -delete
> find $(TARBALL_DIR) -name "*.exe" -not -path
> "$(TARBALL_DIR)/mcs/class/lib/monolite/*" -print -delete
>
> There was no directory external/binary-reference-assemblies/ in 3.2.8.
> What will you do for 4.0 for the Debian packages?

The official Debian packages will not contain that directory at all. The
"+dfsg" suffix in a version number in a Debian orig tarball signifies
that it has been altered to comply with the Debian Free Software
Guidelines (which, like Fedora, forbid inclusion of needless binaries).
4.0.0 in Debian will be +dfsg'd.

Technically the binaries in question are Free Software - they have been
produced from Free source, with Free tools - but they cannot be produced
by the mono 4.0.0 source tree (they're built from a 3.12 source tree).

The Xamarin packages include the binaries, as that no-binaries
requirement is not a requirement (although it is a personal
nice-to-have, as a FOSS guy).

The binary-reference-assemblies files are needed when trying to compile
software which needs to target an older .NET version than 4.5 (which is
all Mono 4.0 supports natively) - if you don't care about that
requirement, then the binary-reference-assemblies simply are not needed.

> Can we join efforts to build the external binaries somehow during the
> package build process?
> Or do we need to create separate packages for the external binaries?

You would need a "mono_3.12.1" source package as a distinct and separate
source package from "mono". The build process would look approximately
like "configure && make && run CLI-stripping tool whose name I've
forgotten && manually package files in question without using make install"

This isn't a discussion I've had within Debian yet, as the 8.0 release
freeze means Mono updates haven't been a topic of discussion. My
*personal* feeling is "I don't care enough about building against old
frameworks to put in the work, I'd rather just delete the files entirely"

> Another question about monolite: Did you negotiate in the Debian
> project to keep the monolite binaries, so that you can build Mono
> without requiring Mono during the build?
> I have just tested to build Mono without monolite on Fedora 21:

Typically, decisions on such matters are made by the FTP Masters, whose
job is to gatekeep uploads by developers. A clear explanation of why
certain binaries have been kept, and a sworn statement that those
binaries can be regenerated by the source tree in question, has been
fine IME (see also F#, VBNC... compilers, generally). I couldn't find
the specific policy clause covering this whole topic, though. Doesn't
mean it's not there, just that our search mechanisms suck.

When a compiler is self-hosting, that tends to also mean it needs itself
in order to compile, and any casual observer would agree that "contains
a minimal copy of itself to bootstrap itself" is better than "circular
build dependency on itself, meaning the archive can never be cleanly
rebuilt from source" - although instances of both exist in the Debian
archive.

> build/common/basic-profile-check.cs(40,30): error CS0117:
> `System.Version' does not contain a definition for `TryParse'
> /usr/lib/mono/2.0/mscorlib.dll (Location of the symbol related to
> previous error)
> build/common/basic-profile-check.cs(43,21): error CS0165: Use of
> unassigned local variable `version'
> Compilation failed: 2 error(s), 0 warnings
> build/profiles/basic.make:93: recipe for target
> 'build/deps/basic-profile-check.exe' failed
> make[6]: *** [build/deps/basic-profile-check.exe] Error 1
> *** The compiler 'mcs' doesn't appear to be usable.
> *** You need Mono version 3.8 or better installed to build MCS
> *** Check mono README for information on how to bootstrap a Mono installation.
> *** The version of 'mcs' is: Mono C# compiler version 2.10.8.0.
> build/profiles/basic.make:60: recipe for target 'do-profile-check' failed
>
> It seems that Mono 4 Alpha 1 does not build with the old Fedora Mono
> 2.10 packages anymore.

I don't believe the 3.8 requirement is entirely accurate, but 2.10 is
certainly too old. This is a great illustration of my point from above,
actually - a blanket ban on self-hosting bootstrap binaries makes it
tedious and incremental to update to latest. Unfortunately, it seems
Fedora packaging policy is "hooray for tedious and incremental". You
should have some luck with the spec files I use for Xamarin RPMs, at
https://github.com/directhex/xamarin-mono/tree/centos (I haven't been
tagging releases as I should - my development process is still very
Debian-centric - a gap of several days is a good indicator that I did an
upload). These are based on what was the state of the art in openSUSE
when I started my job, but with a bunch of changes to better cope with
gaps in RH's version of RPM.