Hi,
* Timotheus Pokorra <timotheus.pokorra(a)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
--
PGP Key: 66484681 (
http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681