Hi,

* Timotheus Pokorra timotheus.pokorra@solidcharity.com [2016-11-04 07:27]:

I have already done some investigations on this, so my findings (and questions) might help the SIG to get started on packaging dotnet for Fedora.

I had to package dotnet for RHEL and it was very, very, painful. There is some work going on .NET Core upstream to make this easier, but I don't know when it will be finished and available for use.

To comply to the rules of Fedora packaging, the packages must be able to build themselves. The exception is a bootstrap ([0] and [1]), where we are allowed to use provided binaries, with approval from the packaging committee.

One thing to note is that .NET Core often requires non-released versions to build a new version. Upstream .NET Core relies on having recent nightly builds available and will mostly use that to build itself. The build scripts for most .NET projects roughly do this:

1. Download a recent (nightly) version of .NET Core 2. Restore (download) all NuGet packages listed as dependencies 3. Build everything 4. Build NuGet packages

For example, I was not able to use to .NET Core RC2 to build .NET Core 1.0; I had to use a newer nightly build than RC2 to build 1.0. I have a suspicion that we will need some preview build of .NET Core 1.1 to build.NET Core 1.1-final as well.

Some trouble will be the number of nuget packages that are pulled in during the build process. We need to package each individually I guess.

Pretty much, unfortunately.

From my current understanding, we have these first candidates for packages:

• dotnet-cli [2]
• dotnet-coreclr [3]
• dotnet-corefx [4]
• msbuild [5]

The list of dependencies needed to build .NET Core 1.0 is quite a bit longer, unfortunately.

Here's a list of github repos of projects that included included into the build (and so shipped with .NET Core). This does not include projects (like msbuild) that are only used to build .NET Core and not shipped/included into .NET Core.

- dotnet/cli (this actually builds what is generally distributed as .NET Core) - dotnet/coreclr - dotnet/corefx - dotnet/core-setup - Microsoft/ApplicationInsights-dotnet - NuGet/NuGet.client (and submodules) - JamesNK/Newtonsoft.Json - dotnet/roslyn - dotnet/symreader - aspnet/libuv-build - aspnet/libuv-package

Sadly, there's no automated or canonical way to obtain this list. If it changes at any point, there's no obvious way to find out, other than trying to build with a custom NuGet cache, disable the network and watch as the build fails.

If you include just build time dependencies, the list is much longer (but I never made such a list one).

If I understand correctly, msbuild can be built with target Mono or target CoreCRL. There is ongoing work on the xplat branch of msbuild to target Mono [6]. The question if we end up having two packages, mono-msbuild and dotnet-msbuild? Is mono-msbuild at all useful for dotnet, ie. can we compile dotnet packages with mono-msbuild? That needs to be investigated.

FWIW, I didn't build msbuild for .NET Core 1.0; it's not required at runtime. I don't know if this will change for .NET Core 1.1.

dotnet-corefx depends on dotnet-coreclr?

Not, exactly. CoreFX depends on all of .NET Core (plus msbuild and various other build-time dependencies) to build. It may also depend on CoreCLR artifacts explicitly; there's some circular build dependencies.

CoreCLR is mostly native code, but it also builds some NuGet packages. So it also needs .NET Core.

Both depend on dotnet-cli?

Yes. Pretty much every component needs a VM that can execute .NET applications - as part of the build scripts. And they pull in the entire .NET Core as the build tool rather than just the CoreCLR VM.

Can you shed some light on these questions?

After building .NET Core 1.0, I can give an entire talk on how to make your project impossibly hard to build from source. All examples would be from .NET Core ;)

Thanks, Omair