Bug 1159091 (openra) - Review Request: openra - Libre/Free Real Time Strategy project [+Tracker to unbundle all dependencies]
Summary: Review Request: openra - Libre/Free Real Time Strategy project [+Tracker to u...
Keywords:
Status: CLOSED NOTABUG
Alias: openra
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Nobody's working on this, feel free to take it
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: NotReady
Depends On: 1089278 1089426 fuzzynet 1220138 1221559 sharpziplib newtonsoft-json maxmind-db 1270776 maxmind-geoip2 1279087 sdl2-cs openra-eluant smartirc4net 1305303 1313828 1315057
Blocks: FE-GAMESIG
TreeView+ depends on / blocked
 
Reported: 2014-10-30 23:37 UTC by Raphael Groner
Modified: 2018-06-23 03:33 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-11-05 22:20:02 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Raphael Groner 2014-10-30 23:37:16 UTC
Spec URL: https://raphgro.fedorapeople.org/review/openra/openra.spec
SRPM URL: https://raphgro.fedorapeople.org/review/openra/openra-20141029-1.fc20.src.rpm
Description: Libre/Free Real Time Strategy project that recreates
the famous Command & Conquer titles
Fedora Account System Username: raphgro

copr: http://copr-be.cloud.fedoraproject.org/results/raphgro/OpenRA/
koji f21: http://koji.fedoraproject.org/koji/taskinfo?taskID=7986601

rpmlint does not show any true issues besides many false positives.

TODO unbundle 3rdparty stuff like embedded libraries

Note also Mono guidelines:
https://fedoraproject.org/wiki/Packaging:Mono?rd=Packaging/Mono#Distributing_Prebuilt_Assemblies

Comment 1 Raphael Groner 2014-11-06 17:20:26 UTC
(In reply to Raphael Groner from comment #0)
…
> TODO unbundle 3rdparty stuff like embedded libraries

https://github.com/OpenRA/OpenRA/issues/6863

Comment 2 Raphael Groner 2014-12-16 15:28:07 UTC
FYI: Open.NAT¹ is a fork of the somehow dead project Mono.NAT (review request: bug #1166897), and so seems to be the new hope instaed.

Asking upstream² what the plan is or should be.

¹ https://github.com/lontivero/Open.NAT
² https://github.com/OpenRA/OpenRA/issues/7140

Comment 3 Raphael Groner 2015-01-08 22:04:31 UTC
I am waiting for upstream. They promised a patch to remove the b0rken feature to use mono-nat (bundled 3rdparty).

Comment 4 Raphael Groner 2015-03-31 16:19:24 UTC
Upstream gave up with a port to use Open.NAT instead of upstreamly dead Mono.NAT.

Comment 5 Raphael Groner 2015-11-07 20:52:42 UTC
(In reply to Raphael Groner from comment #4)
> Upstream gave up with a port to use Open.NAT instead of upstreamly dead
> Mono.NAT.

This decision could be overthought and reverted at upstream cause of a PR to backport of Open.NAT to .NET 3.5
https://github.com/lontivero/Open.NAT/pull/31

Comment 6 Matthias Mailänder 2015-11-21 12:09:45 UTC
I already built Mono.NAT for Fedora 22 10 months ago at: https://build.opensuse.org/package/show/games:openra/mono-nat

Comment 7 Raphael Groner 2016-01-15 13:26:48 UTC
Upstream moved from Mono.NAT to Open.NAT, see
https://github.com/OpenRA/OpenRA/pull/10281

I'll start a new review request for Open.NAT .

Comment 8 Matthias Mailänder 2016-03-02 19:34:30 UTC
After a long hiatus we decided to do that not yet, because it is not possible to get Mono or .NET >= 4.5 to run on Windows XP which parts of the community still use. https://github.com/OpenRA/OpenRA/pull/10279

Comment 9 Raphael Groner 2016-11-05 22:20:02 UTC
After a long hiatus I decided to fully stop my work with OpenRA packaging. Unfortunately, there are too many unresolvable issues with the bundled libraries and upstream is unwilling to accept proposed solutions and denies patches.

Comment 10 Matthias Mailänder 2016-11-06 06:53:03 UTC
Which patches from your side were denied? Maybe I can take a look and talk to Paul.

Comment 11 Matthias Mailänder 2016-11-06 06:55:22 UTC
Note, that we ditched Windows XP support in favor of modern Linux variants https://github.com/OpenRA/OpenRA/pull/11284 even though that caused a minor shit storm. http://www.ppmforums.com/viewtopic.php?t=42725

Comment 12 Raphael Groner 2016-11-06 16:24:54 UTC
(In reply to Matthias Mailänder from comment #10)
> Which patches from your side were denied? Maybe I can take a look and talk
> to Paul.

Let's assume you read my reports on GitHub and I don't want to invest my costly time to explain the same things again and again to repeat my feeling about noone understood.

Comment 13 Matthias Mailänder 2016-11-07 06:06:00 UTC
I haven't subscribed to the whole OpenRA bug tracker anymore as the sheer amount would blow up my inbox and I decided to step down from development a bit. Can you maybe list your key blockers? I can try to work on them during the holidays and put them back on the agenda.

I know that it is way easier to bundle everything and that clean cross-platform C# dependencies is still a long way to go. Sometimes you have to make compromises especially when dealing with a large group of non-technical consumers and you only have very limited free time to support them.

See also my experiments at https://build.opensuse.org/project/show/games:openra where I even went through the madness of doing so in a cross-distribution way.

Comment 14 Jeremy Newton 2016-11-21 18:01:31 UTC
Unbundling third party libraries shouldn't be a hard blocker anymore due to changes in Fedora's policies. Is there licensing issues? If not, this should still be good to package, providing any bundled software (that can't be removed) is built from source and the necessary "Provides: bundled(*)" are added.

Comment 15 Matthias Mailänder 2016-11-21 19:57:02 UTC
If getting software into Fedora is such an bureaucratic, time-consuming and laborious we could also collaborate together on a FlatPak/AppImage bundle that works across distributions. https://github.com/OpenRA/OpenRA/issues/12257

I guess this task will fail anyway in the IP review as OpenRA relies a lot on foreign intellectual property. Even though trademarks are avoided, the code is a clean room implementation and most of the assets are hosted separately on a community mirror server with silent approval from Electronic Arts, I assume licensing and redistribution of files as in https://github.com/OpenRA/OpenRA/tree/bleed/mods/ra/bits are a real problem, that has to be addressed first.

Comment 16 Matthias Mailänder 2016-11-21 19:57:44 UTC
If getting software into Fedora is such an bureaucratic, time-consuming and laborious act, we could also collaborate together on a FlatPak/AppImage bundle that works across distributions. https://github.com/OpenRA/OpenRA/issues/12257

I guess this task will fail anyway in the IP review as OpenRA relies a lot on foreign intellectual property. Even though trademarks are avoided, the code is a clean room implementation and most of the assets are hosted separately on a community mirror server with silent approval from Electronic Arts, I assume licensing and redistribution of files as in https://github.com/OpenRA/OpenRA/tree/bleed/mods/ra/bits are a real problem, that has to be addressed first.

Comment 17 Jeremy Newton 2016-11-21 22:35:36 UTC
(In reply to Matthias Mailänder from comment #16)
> If getting software into Fedora is such an bureaucratic, time-consuming and
> laborious act, we could also collaborate together on a FlatPak/AppImage
> bundle that works across distributions.
> https://github.com/OpenRA/OpenRA/issues/12257
> 
> I guess this task will fail anyway in the IP review as OpenRA relies a lot
> on foreign intellectual property. Even though trademarks are avoided, the
> code is a clean room implementation and most of the assets are hosted
> separately on a community mirror server with silent approval from Electronic
> Arts, I assume licensing and redistribution of files as in
> https://github.com/OpenRA/OpenRA/tree/bleed/mods/ra/bits are a real problem,
> that has to be addressed first.

IMHO, most of the bureaucratic issues came down to the strict no-bundling policy and a few other issues that have since been reworked and "loosened".

Although in regard to the "foreign intellectual property", I can imagine you are correct, but I can't speak for the legal team.

RPMFusion could be used to package this if legal rejects this, but with that said, I would still think that a FlatPak would be the easiest option.

Comment 18 Matthias Mailänder 2017-02-05 08:54:36 UTC
I managed to drop 2 dependencies with https://github.com/OpenRA/OpenRA/pull/12702 with the help of the Maxmind C# developers.

Comment 19 Brenton Horne 2017-11-14 04:00:40 UTC
Any progress on this bug? I rather like this game too and it'd be nice to see Fedora becoming one of only two distributions I'm aware of with it in an official repository with the other being Arch Linux.

Comment 20 Matthias Mailänder 2017-11-16 11:59:35 UTC
No, not really. I also lost interest. As the Mono/.NET distribution packaging isn't really working well and it's not looking like it's getting better in the future after the acquisition of Xamarin from Microsoft, the OpenRA team will probably look into containerized apps, but hasn't really decided on what format to choose:

* https://github.com/OpenRA/OpenRA/issues/12663 FlatPak
* https://github.com/OpenRA/OpenRA/issues/12257 AppImage
* https://github.com/OpenRA/OpenRA/issues/11133 Snap

Comment 21 Brenton Horne 2017-11-16 12:04:43 UTC
I actually filed the AppImage request, but my guess is a decision is months, if not years away, hence why I'm interested in distro-specific packages. But I suppose such is life, at least there's unofficial OpenRA packages available for Fedora.


Note You need to log in before you can comment on or make changes to this bug.