-
Notifications
You must be signed in to change notification settings - Fork 14
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
Possibility to turn back on the network sandbox for .NET builds #25
Comments
Hello! Thanks for the feedback, I appreciate it. I agree, the .NET packaging could be greatly improved (lack of time, priority...). I think that creating an Exlib now is not really necessary (we have very few packages, and EventStore is not really used anymore...). But no doubt I'd take a look at your work at Gentoo if I had to create an Exlib in the future! Do you plan to create a .NET ebuild from source (I've only seen a dotnet-sdk-bin package)? Packaging from source is always a pain (very long, many errors, patches to do...) and having an equivalent package at Gentoo would very useful. |
I will explore that in near future for the mentioned overlay. |
@s0dyy It is possible to build dotnet w/o net access but it has to have a special bootstrap tarball. See: |
Hello! I'm currently developing eclasses for Gentoo to support packaging .NET applications.
At the time of writing it is possible to not violate the network sandbox while building .NET packages for Gentoo if using the
dotnet-pkg
eclass from the experimentalgentoo-dotnet-2023
overlay.Eclasses:
Example packages:
Thought I would share this because i see you are fighting the Paludis's sandbox for building .NET apps.
See: https://github.com/CleverCloud/CleverCloud-exheres/blob/7bdd08d9c96952e2602a35b492c3b6743d365e31/packages/dev-db/EventStore/EventStore-21.10.8.exheres-0
The text was updated successfully, but these errors were encountered: