-
Notifications
You must be signed in to change notification settings - Fork 7.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fedora RPM #1882
Comments
Ah yes, we'll need to start building for |
Pretty please! |
@gtirloni this hn comment explains a method to get it working on Fedora 24. But yes, a native package would be nice. |
Any chance the .spec file used to build the current RPM could be released to make it easier to figure out how to package for other distros? |
@ImNtReal judging from |
As a temp workaround, I was able to get it running using https://nmilosev.svbtle.com/running-net-core-rc2-on-fedora-23 |
In the meantime for Fedora 24, install the older LibICU package from ftp://195.220.108.108/linux/fedora/linux/releases/23/Everything/x86_64/os/Packages/l/libicu-54.1-5.fc23.x86_64.rpm as per this dotnet issue. |
Using fpm for rpm and .deb generation is sub optimal. Source rpms and .deb files are desirable for a repeatable build outside someone's random build environment. This will be important for acceptance in enterprise distros as well as Debian. I strongly recommend looking at https://openbuildservice.org for Linux builds as it not only covers a wide range of popular distros, but easily supports building on non X86 arches, everything from tiny Arm5 to IBM mainframes. OBS as we call it is 10+ years of maturity and the most powerful build platform for native Linux packages. If the build team is in Redmon, I'll gladly drop in and show them how it works. It also integrates with Jenkins/Git workflows for CI. |
Totally agree, but it was very quick to go from zero to multiple packages 😉 I'm unclear if we should own the creation of packages for distributions to release. My understanding is that usually outside package maintainers pick up your build output and source, and create packages for their distribution; not pickup packages from you. However, I don't know if this is the route they'll take with PowerShell. If distributions end up wanting us to maintain the actual packages going into their repositories, we absolutely will need to create them from scratch (RPM spec etc.). |
It would be ideal to have packages accepted into the official repositories but that usually requires quite some time from maintainers. I think it's unreasonable to request this from open source projects. If there are volunteers or a company with a vested interest in having these packages, then I'm sure we'll see that in time. It's completely acceptable for the upstream project to only provide packages generated through fpm. It's already much better than just releasing the source code or some zipped binaries. As for this specific issue, rebuilding on Fedora 24 with the correct requirements properly defined and a new RPM being made available through the website is all that's needed, in my opinion. |
Maybe people from RedHat get interested in or can be convinced to getting respective packages sooner into their upstream Linux |
CentOS provides a Docker container with Powershell installed. Why not just use it and a shell function to start it? Maybe something like this?
|
@jrm16020, doesn't that defeat the purpose a bit? It's a shell after all; I would like to try powershell as a regular shell for a few days side-by-side with my usual shell. Wouldn't that be impossible when using a docker container? |
Running apps directly from a docker container is not that unusual these days. A lot of convenience has been added around launching applications this way. I guess that's what @jrm16020's script tries to achieve. Mounting the current directory into the container might not be enough. Actually, I guess that everything that is accessible (file system, internet, registry etc.) through powershell would have to be mounted into the container so that it feels like working natively. All that said, it's probably not impossible but a lot of work is to be done, bringing all into the container. I bet it is easier to build native executables that work directly on your 'disclosed' OS. |
No, not really. The example that I posted above works for my use case but it's not a big deal to modify it to serve your purposes. In your case you'd run a privileged container and mount all of your local filesystem into the container. Your container will already have the networking capabilities that your bash/zsh/dash shell has since it's a privileged container and has access to any of the binaries of your Linux host.
I don't mean to discount the request for native Fedora packages. I'm a Fedora user and would enjoy seeing a native package as well. That said, there are ways to get Powershell working on your system as it's currently built without depending on an RPM. Docker is the perfect way to package software for easy consumption by all Linux distributions. |
Maybe this workaround could help. (source: https://news.ycombinator.com/item?id=12314693)
|
Awesome! I able to install PowerShell 6.0 on Fedora 24 Desktop OS. The instructions in the link provided by Imward works: https://nmilosev.svbtle.com/running-net-core-rc2-on-fedora-23 Woohoo! |
For anyone who wants to get started on this, the minimum requirements would include: To get it working:
To get it published:
The PowerShell maintainers are adding this to GitHub and Digital Ocean's Hacktoberfest for anyone wanting to participate. .NET Core supports Fedora 23. |
The download.sh say 'Fedora is not supported!' , using Fedora 23 (4.7.10-100.fc23.x86_64). When trie to run PowerShell 'Failed to initialize CoreCLR, HRESULT: 0x80131500'. I didn't do the downgrade libicu to libicu-50.1.2-15.el7.x86_64.rpm |
Would definitely love to see this supported on current versions of Fedora! |
Another Fedora (24) user here: Following the above suggestions, I felt uncomfortable about using old versions of openssl! I found that Mageia Cauldron packages a more recent libssl.so.1.0.0 (1.0.2j at time of writing), and using this satisfied my conflicting "get it working" and "be safe" requirement. So I'd suggest taking whatever lib64openssl1.0.0-xxxxxxx.mga6.x86_64.rpm is provided in http://mirrorservice.org/sites/mageia.org/pub/mageia/distrib/cauldron/x86_64/media/core/release/ & using that instead of the 1.0.0i from Fedora 17. |
@AndrewSav I brought the changes back in #2982; however, the work done so far enables the RPMs to be built, but does not make them part of the build process. I have #3026 open for updating the documentation and adding Fedora RPMs to the releases. I'll reopen this until the issue is completed. |
I think there is a copr repo managed by @nmilosev for dotnet CLI (https://github.com/dotnet/cli/issues/4866) already, it addresses this specific libicu problem on Fedora, would it be possible to reuse some of their infrastructure here ? |
@cyplo, I'm sorry if this is completely off the mark, but the copr repo simply downgrades libicu If I understand it correctly. I understand this is undesirable as a permanent solution, since something else might require the latest version of libicu. |
Hi, this package avoids the libicu issue by rebuilding core components of the framework (CoreFX, CoreCLR, libuv, core-setup). We are also using SDK built for RHEL by a RHEL developer Omair. We had to go this way, instead of bundling libicu because Fedora's policies forbid bundled libraries. (https://fedoraproject.org/wiki/Bundled_Libraries?rd=Packaging:Bundled_Libraries) There was a pull request in one of the repos which fixes the libicu issue. If you download 2.0 nightly builds, libicu issue is non present. Sadly it didn't make it in 1.1.1 release. All the code for Fedora's package is hosted here on F25 branch: http://pagure.io/fedora-dotnet Pinging @omajid @tmds @RheaAyase |
Please refer to https://fedoraproject.org/wiki/DotNet for Fedora .NET Core packages, always up-to-date reference to whatever you're looking for. |
After ending up on this post, I finally installed PowerShell on Fedora 25 as following: As explained here, fist install the Fedora .NET Core package:
Then download the RPM for CentOS 7 and install it. You are now able to execute the statement below to open the PowerShell prompt: |
For future readers - Please always refer to the source about installing anything, do not use copypasta cut out of other places, because it will not be updated and maintained here. Look up these instructions on Fedora .NET wiki (which will refer you to the right download instructions for your version) |
You are correct, comment updated. |
What's the status of this issue? I believe our RPM release is working with Fedora 27? |
That's not how packaging works in Linux. Open Source products are built and packaged by package maintainers, not by the authors of the products. Yes, one may be both, but in the case of .NET Core that is in no way true. Package maintainers can make sure that said product works with all the quirks of their Linux distribution, and they have to comply with it's rules. Among the many rules of Fedora packages, one of the main ones is that the packages have to be fully built from source, including the tools used to do so. All done in Fedora, for Fedora. This way we can make sure that there is nothing spooky coming from some 3rd party binary that could cause issues or vulnerabilities, etc... .NET Core is packaged by the Fedora .NET SIG and all the information around .NET Core in Fedora is maintained and always up to date at fedoraloves.net On a side note, as you can also find out on our pages, .NET Core, VSCode and other packages published by Microsoft are not free software, are under proprietary licenses, and contain proprietary code and libraries. We exclude these bits and pieces from our packages and provide necessary hacks to get the sh!# to work. Now on topic of PowerShell packages themselves, I've not looked into it so I can not tell if it's the same as the above and with the same issues. From a glance from afar, those are not Fedora packages. They're rhel packages. There is major difference, so I expect a huge load of issues. (I'll take a closer look some time next week.) |
https://docs.microsoft.com/en-us/powershell/scripting/install/install-fedora?view=powershell-7.2#installation-via-package-repository successfully installs PowerShell for me. Consequently, does this issue exist to ensure that the package is added to Fedora's default repository? |
Official support for Fedora appears to have been revoked, which explains why the hyperlink (https://docs.microsoft.com/en-us/powershell/scripting/install/install-fedora?view=powershell-7.2#installation-via-package-repository) that I previously provided (at #1882 (comment)) is inoperative. Does that invalidate this issue? I hope not: the RPM is perfectly operative for me, so this decision appears to be unreasonable. |
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you. |
1 similar comment
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you. |
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you. |
@jw, I mean that https://docs.microsoft.com/en-us/powershell/scripting/install/install-fedora was replaced by solely https://learn.microsoft.com/en-us/powershell/scripting/install/install-rhel?view=powershell-7.4. RHEL isn't Fedora, even if their
|
This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes. |
Please provide RPMs for Fedora too.
The CentOS RPM isn't a workaround because it doesn't work on Fedora 24 at this moment:
The text was updated successfully, but these errors were encountered: