Build RPMs

[mickaelistria]

Installation of Fedora currently require several steps, including preparing dependencies.
RPM are the solution for that, as they would also allow to express constraints (such as explicitly binding to the right version of icu at install time). It would be much better to have rpms to install dotnet on Fedora et al.

[TheRealPiotrP]

@ellismg any updates on this?

[gusennan]

Would love to see this too.

[tezine]

+1 for dotnet rpm for fedora 25

[TheRealPiotrP]

Anyone up for making a PR?

[volviq]

There are RPMs in the download section - so obviously was done but not documented in this issue - but they don't seem to be well structured: It seems not all dependencies are set in the .spec, so it is possible to install them without having the required components in the system.
Issues like #5455 should't arise after installing from RPM, but I got an error and realised that icu was not installed on the system.

[aignas]

Just wanted to let others now, that there is a Fedora dotnet Special Interest Group and as a result of their activity there is a new copr repo, which contains packages that actually work on F25.

I would wait for them to finish the work on https://github.com/nmilosev/dotnetcore-fedora-rpm/ but IMHO it would be good to hear more from @nmilosev himself as well. :)

EDIT: in case you want to know what files where installed, you can run dnf repoquery -l dotnetcore

[nmilosev]

Hey there, thanks for the ping.

Yes, we are building the RPM's for Fedora 25. There are some issues however, which prevent us from including the packages into the default Fedora repositories. To be included in Fedora, a package must be fully built from source, which we hope to achieve with the source build. For now we are using the bootstraping Rover tool with binaries from RHEL for the payload. All the latest development is here: https://pagure.io/fedora-dotnet/branch/f25

I've been in touch recently with @bleroy to allow me early access to the new build system. This way we can try and package a new RPM for Fedora as soon as possible.

These RPM's from the dotnet-clean COPR and also from dotnet1.1 COPR (https://copr.fedorainfracloud.org/coprs/nmilosev/dotnet1.1/) are just there to be used in the meantime.

That saying, I've been using .NET Core on Fedora 24 and 25 for some time now without any issues.

I hope with the new linux.x64 runtime and new buildsystem it will be easy to include everything in the next major Fedora release.

Pinging @tmds @RheaAyase and @omajid if I forgot to mention something.

Feel free to join us for our weekly meetings at the IRC. :)

Kind regards,
Nemanja

[RheaAyase]

Yes, dotnet should be ready for packaging by F26, hopefully.

@tmds, @omajid and myself are actually from RedHat and we used the same built binary we used for RHEL to build the F25 copr package. This was a bit of a shortcut to not have to reinvent the same wheel we already did for RHEL. Looking forward to having an actual build pipeline soon =)

As @nmilosev said, you are welcome to join #fedora-meeting at 19:00 UTC on Tuesday. more info on the mentioned wiki page.

Oh and @aignas, you are referring to github page - please note that this is out of date and we use pagure.

I think that this ticket is slightly off-topic from the dotnet itself though. It is up to the individual linux distributions to package and release it properly, and .net foundation has very little to nothing to do with that process. I would suggest closing it.

Regards,
Radka

[JohnRusk]

Will be great if there are RPMs not just for the SDK (as there are in some cases now) but also for the Shared Runtime only. As per dotnet/cli#5773

[livarcocc]

@ellismg can you give us an update on this?

[ellismg]

I believe that @rakeshsinghranchi was working on building an RPM to complement the .deb (or knows who was doing the work). My understanding is it will still land for 2.0.

[tmds]

@ellismg I hope we still have it as a goal for the Fedora dotnet SIG to be able to compile and package .NET Core 2.0 for F26.

[livarcocc]

@ellismg is @rakeshsinghranchi taking care of that for the CLI as well?