I was just wondering about the following few things, that @tmds or @omajid would know an answer to...
Why is Fedora missing here? I think that I am missing something... https://github.com/dotnet/corefx/blob/master/pkg/Microsoft.NETCore.Targets/runtime.json
Can we update to F24 AND F25 and obsolete 23 out? https://github.com/dotnet/corefx/blob/master/src/Common/perf/project.json ...I find it funny that somewhere it's just F23, elsewhere we can see F24... I would like some consistency eh (and well, to get rid of the obsolete 23 anyway) https://github.com/dotnet/corefx/blob/master/pkg/Microsoft.Private.CoreFx.NETCoreApp/Microsoft.Private.CoreFx.NETCoreApp.props https://github.com/dotnet/corefx/blob/master/pkg/baseline/project.json
I find this whole thing funny for some reason hehe: https://github.com/dotnet/corefx/blob/master/init-tools.sh https://github.com/dotnet/corefx/blob/master/buildpipeline/pipeline.json
Not that it's any kind of news, but the joke doesn't end there though... It's everywhere! Just a quick search to see how much of it is out there turns up with a too much response: https://github.com/dotnet/coreclr/search?utf8=%E2%9C%93&q=fedora+23&type=Code https://github.com/dotnet/cli/search?utf8=%E2%9C%93&q=fedora Maybe it would be worth thinking about using more generic Fedora instead of always fedora-23 or whatever. I'm trying to think about a way to make it tick with fast pace distro like Fedora >_<
too much
...
I think that i got carried away :D
Metadata Update from @rhea: - Issue tagged with: upstream
Hey.
Why is Fedora missing here?
https://github.com/dotnet/corefx/blob/master/pkg/Microsoft.NETCore.Targets/runtime.json
I don't know what this file does. Fedora (23, 24) is present in the Microsoft.NETCore.Platforms version, which defines the official RIDs: https://github.com/dotnet/corefx/blob/master/pkg/Microsoft.NETCore.Platforms/runtime.json
Can we update to F24 AND F25 and obsolete 23 out?
It's quite silly. Microsoft maintains a list of platforms it supports and publishes binaries for. I am not sure we can tell them to what to support and what to obsolete. We should tell them that F23 has been EOL'ed.
Not that it's any kind of news, but the joke doesn't end there though... It's everywhere!
Yes, this is a huge flaw in how they build their packages. Instead of building for current OS, runtimes, their build system (mostly) builds for all known runtimes, which means the runtimes are defined (and re-defined, and re-re-defined) in dozens of places.
Speaking with some Microsoft folks, they have pointed out that their new source-build work will take the existing projects and basically insert the current runtime id in there and then build that. Hopefully there won't be a need to keep on updating runtime ids.
See https://github.com/dotnet/core-setup/issues/1551#issuecomment-280091431
I would like some consistency
I am starting to think it's a lost cause. I a have been trying to fix things to build on RHEL 7.3. Upstream supports RHEL 7.2. 7.3 is supposed to be backwards compatible yet I have to update dozens of places to get to a state where I can build things in RHEL 7.3 at all.
A better longer term solution would be to stop embedding all the runtime id. Maybe define them in one location, max. Better would be to just build things for the current runtime id, which is hopefully what the source-build project does.
Think that it's something worth bringing up in an actual meeting on Thursday or just drop it in Slack or spark an issue discussion? There is this old one that seems kinda forgotten... https://github.com/dotnet/corefx/issues/14469 ...but it is mentioning the new build and what not which is all really fresh, even now. So I guess that we wait a bit more til those things are sorted out, and then see about replacing F23/24 with something better (By then even 24 will be eol eh)
A better longer term solution would be to stop embedding all the runtime id. Maybe define them in one location, max.
Yes, that...
Login to comment on this ticket.