[dotnet] Packaging dotnet for Fedora

[Timotheus Pokorra]

Hello,

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.

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.

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.

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

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

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.

dotnet-corefx depends on dotnet-coreclr?
Both depend on dotnet-cli?
Are those statements correct?
I have not tried that yet.

Omair, by the way, good to have you onboard!
Can you shed some light on these questions?

All the best,
  Timotheus

[0]: https://fedoraproject.org/wiki/Packaging:Guidelines#Exceptions
[1]: https://fedoraproject.org/wiki/Packaging:Guidelines#Bootstrapping
[2]: https://github.com/dotnet/cli
[3]: https://github.com/dotnet/coreclr
[4]: https://github.com/dotnet/corefx
[5]: https://github.com/Microsoft/msbuild
[6]: https://github.com/Microsoft/msbuild/tree/xplat

[dotnet] Re: Packaging dotnet for Fedora

[Omair Majid]

Hi,

* Timotheus Pokorra <timotheus.pokorra(a)solidcharity.com&gt; [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

[dotnet] Re: Packaging dotnet for Fedora

[Timotheus Pokorra]

Hello Omair,

thank you for your detailed and open reply!

>  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. 
For myself, this
means I will wait a little longer before actually
trying to package .NET Core for Fedora properly.
But someone else might be more motivated than me to do this...

>  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: 
I hope this will settle once
.NET Core becomes more stable.

>  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 ;) 
Thank you very much for your response!
It has helped me to estimate the effort of the task ahead, and cleared
up a the fog about the dependancies!

All the best,
  Timotheus