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
Bundled thirdparty #6863
Comments
|
See https://build.opensuse.org/package/show/Mono:Factory/mono-nat for a start. |
|
Thanks for the hint. mono-nat is already in Fedora but orphaned. I guess it would need some love and interpolation. 02.2012: "no upstream development for more than a year and no more need in fedora since monsoon is retired as well" |
|
We can't migrate to Open.NAT yet as we are still on the .NET client profile 4.0 #5466 (comment). |
|
The SharpZipLib is not the version bundled with Mono, but the latest found in upstream. See https://build.opensuse.org/package/show/Mono:Community/sharpziplib for a package. |
|
I also plan to migrate on an upstream released version of OpenGL/AL/SDL C# bindings. #6893 See https://build.opensuse.org/request/show/260109 for an RPM package. |
|
Thanks for the information. Does that mean Fedora should wait with the official package review till the next official release of OpenRA will be available? I would suggest so to avoid possibly doubled work effort, and we can continue to discuss the unbundling process here in this issue ticket. |
|
I suggest to start packaging the https://github.com/OpenRA/OpenRA/tree/bleed/thirdparty CLI dependencies in Fedora already. SDL2-CS.dll is probably going away here and tricky for packaging and IP review because it mixed licenses, had no releases and included parts of other projects. So I suggest you do that last or if it takes longer than our release cycle skip it. |
|
See also the discussion at #5485. |
|
So does that mean you will always support the official versions of libraries shipped in Fedora? https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries |
|
That shouldn't be a problem as long as the libraries are well behaved. The main exception ATM is our version of Eluant, which relies on a couple of custom changes that I haven't attempted to merge upstream yet. |
|
Sorry but I don't understand the comment about Eluant. You provide a README file that clearly states you are using concrete libraries from respective authors. Where is the hint that Eluant should be patched and please reference those patches? |
|
The readme file references my Eluant fork, which has the openra-specific patches. |
|
Okay, I did not see the already done fork. But that means trouble for me: Should I package the official Eluant or your fork or both? I can wait till the patches will be applied but that would mean a blocker for the review of OpenRA. |
|
The Makefile does not support to install only the OpenRA assemblies. Please provide a new make option without the hard dependency to bundled dll files, probably by refactoring. That patch should be easy. |
|
In my opinion: Makefiles are for simplicity. If there are n more steps (or targets to invoke) then the whole point is moot. |
|
It may be simpler for the fedora package to patch these lines out in the short term. |
|
We can do a new target install-dependencies. That should be no problem. I guess the main problem is to also link against those system libraries in the first place instead of the hard-coded ./thirdparty/*.dll location. https://github.com/OpenRA/OpenRA/blob/bleed/Makefile#L40 |
|
I packaged nunit https://build.opensuse.org/request/show/266089 and nuget https://build.opensuse.org/request/show/266032 today. |
|
#7346 removes the |
|
#7479 will remove the last Windows binary from the source tarball. |
|
This is not yet resolved completely. |
Please provide build instructions for all the 3rdparty libraries etc.
In Fedora, distribution of prebuilt assemblies is not allowed. All has to be based on available sources, also for legal reasons.
https://fedoraproject.org/wiki/Packaging:Mono?rd=Packaging/Mono#Distributing_Prebuilt_Assemblies
The text was updated successfully, but these errors were encountered: