[mono-packagers] binaries in tarball

Mon Apr 13 06:52:51 UTC 2015

Hello Jo,

thank you for your detailed reply!
This is very helpful!

I will try to build now without the external binaries.

Fedora might decide to go for a 3.x Mono first, avoiding problems with
monolite. We will see.
I am not at all much involved yet with the Fedora culture to know how
decisions are made.

I have joined the IRC #mono on gimpnet.

All the best,
  Timotheus

On 10 April 2015 at 11:51, Jo Shields <directhex at apebox.org> wrote:
>
>
> 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.
>

-- 
Kontaktdaten:
in Plauen: 03741 7424995