Wargus split from Aleona's Tales

[mimooh]

Tim, the promised split is ready and once you are done with the real stuff (the desyncs) you can see about my work. Both wargus and aleona work and can live in parallel. Once we decide upon how aleona package will be available we will provide the necessary info in wargus installation dialogs. Aleona can be forked from here: https://github.com/mimooh/aleonas-tales and hopefully will be hosted next to wargus.

[Kintobor]

Cyber and I put a lot of effort into combining Wargus and Aleona. Why do you want to rip them apart in the repository? Can't you package them on Linux separately without doing that?

I believe the wc2 prefix in the scripts is required for Wargus and Aleona to be compatible.

Some of the maps are set to computer, instead of player. It's on my to do list to go through and fix them all.

[a-detiste]

@Kintobor

I think too they should remain in same repository; (quoting myself);
and then all the history would be lost too, which doesn't help either.

I think one of the problem was that the Warcraft2-exctracted assets would overwrite Aleonas-tales
(which makes "dpkg --verify" and other security tools angry) and then the next Wargus upgrade would overwrite Warcraft 2 assets with Aleonas Tales again.

But I may be completely wrong and I need to check that again.

The split should only happen at the binary packages level (vs source package level)

You don't necesserly have to delete Aleonas Tale assets from main tree.
3a682ee

In Debian terms, that mean stratagus, wargus & aleonas-tales are all in "main/free"
and warcraft2-data ("empty" package with only the postinst script) goes into "contrib".
If someone doesn't want non-free software & disable contrib & non-free repositories, he doesn't see "wacraft2-data" at all.

This way, people choosing to play Aleonas-tales won't be bothered by the postinst/Debconf script.

Some other packagers (? GetDeb) may not care at all and chose to settle for an other logic.

[mimooh]

Well, I just blindly followed some ealier ideas that the split would be
useful and I have no own opinion on it.

Karol Kreński

@Kintobor

I think too they should remain in same repository; (quoting myself);
and then all the history would be lost too, which doesn't help either.

I think one of the problem was that the Warcraft2-exctracted assets would overwrite Aleonas-tales
(which makes "dpkg --verify" and other security tools angry) and then the next Wargus upgrade would overwrite Warcraft 2 assets with Aleonas Tales again.

But I may be completely wrong and I need to check that again.

The split should only happen at the binary packages level (vs source package level)

You don't necesserly have to delete Aleonas Tale assets from main tree.
3a682ee

In Debian terms, that mean stratagus, wargus & aleonas-tales are all in "main/free"
and warcraft2-data ("empty" package with only the postinst script) goes into "contrib".
If someone doesn't want non-free software & disable contrib & non-free repositories, he doesn't see "wacraft2-data" at all.

This way, people choosing to play Aleonas-tales won't be bothered by the postinst/Debconf script.

Some other packagers (? GetDeb) may not care at all and chose to settle for an other logic.

---

Reply to this email directly or view it on GitHub:
#155 (comment)

[mimooh]

I improved cmd line invocation: resources and one peasant only can be now specified with wargus -G. Not sure how to create pull request now, since the previous is still open and seems I cannot start a separate pull request.

I used some fancy lua formatting tool for resources and units changes, since the code didn't have proper indenting under my vim (github diff reads it better, so it seems like different tabstops). Anyway, the changes are less than it looks. Also, some functions in lua scripts are a few screens long, so once I get more proficient with lua, I could refactor the code a little, unless you think it is fine as it is now.

[mimooh]

@Kintobor, the idea for the split seems to come from here:
#145

So what do you think of all this? What if there are more assets? I'd say they should be all parallel, in separate packages. We need to decide something about this issue.

[a-detiste]

Well, the best would be that Warcraft II & Aleonas Tales would use two different namespaces (directories ?) and be co-installable

That still apply; but is much more easier to enforce if wargus & aleaonas tales stay in the same repository

[mimooh]

That still apply; but is much more easier to enforce if wargus &
aleaonas tales stay in the same repository
is wargus/wargus and wargus/aleonas the same repository?
or
is it only wargus/wargus with all data?

Is there anything I could/should do about it now?

Karol Kreński

Well, the best would be that Warcraft II & Aleonas Tales would use two different namespaces (directories ?) and be co-installable

--- Reply to this email directly or view it on GitHub:
#155 (comment)

[timfel]

@mimooh could you put the new commandline option into a separate pull request by pushing it to a new branch? Supposing you have Wargus/wargus as "wargus" and your own fork as "origin", this should be as simple as:

git checkout wargus/master
git checkout -b patch-G
git cherry-pick 03752fc0844d57879f0fccbf668c6c9a190e430f
git push origin patch-G

... and then create a pull request from the "patch-G" branch.

[mimooh]

I'll try that. Also, I find it useful that the server announces his
IP/PORT so that the clients can be told where to connect, as requested
by #33

I could do the lua part probably, but I guess I need to get it from C
somehow. Could you give some basic hint on this?

Karol Kreński

@mimooh could you put the new commandline option into a separate pull request by pushing it to a new branch? Supposing you have Wargus/wargus as "wargus" and your own fork as "origin", this should be as simple as:

git checkout wargus/master
git checkout -b patch-G
git cherry-pick 03752fc0844d57879f0fccbf668c6c9a190e430f
git push origin patch-G

... and then create a pull request from the "patch-G" branch.

---

Reply to this email directly or view it on GitHub:
#155 (comment)