Split 0ad package into pyrogenesis and 0ad
This splits the 0ad package into a pyrogenesis package and a 0ad package.
The 0 A.D. executable pyrogenesis can be useful without the 0ad-data package, for example as a way to create new mods for 0 A.D. when used with -archivebuild. Pulling in the 3GB of data for this task is entirely un-necessary, and makes this awkward to use with e.g. a Docker container should one want to package mods on CI (which is something I've wanted to do recently).
As an alternative, the 0ad-data package could be a 'recommended' package, but I think this might lead to more misunderstandings, particularly since the mod mod is in 0ad-data and not 0ad-data-common.
I must apologise for not being very familiar with the debian packaging system, what I've read leads me to believe that this is all that is necessary to change given that the new pyrogenesis package is essentially just 0ad without 0ad-data. Let me know if there are other changes that would make this a more useful contribution.
(FWIW, I am a 0 A.D. developer)
Merge request reports
Activity
I like the idea.
If I understand correctly the package
0ad-data-commonis, in fact, not specific to 0ad. Maybe it could be renamedpyrogenesis-dataor something similar?Any plan on 0ad upstream to repackage 0ad sources (
0ad-unix-build.tar.xz&0ad-unix-data.tar.xz) into 2 or 3 parts? To have something like:- pyrogenesis
- pyrogenesis-data
- 0ad-data
If I understand correctly the package
0ad-data-commonis, in fact, not specific to 0ad. Maybe it could be renamedpyrogenesis-dataor something similar?From what I can tell,
0ad-data-commoncontains the config/tools folder, and in that case yes you are correct. For that matter, we could just bundle that with thepyrogenesispackage.
As a matter of fact, the only 0 A.D. specific part is really the
public/folder in0ad-data. Themodfolder acts as kind of a minimal mod, but it's technically not necessary to use the engine. This merge request could be changed so that0ad-databecomes0ad, and0adbecomespyrogenesis, and get the same benefits (might be easier).
Any plan on 0ad upstream to repackage 0ad sources (
0ad-unix-build.tar.xz&0ad-unix-data.tar.xz) into 2 or 3 parts? To have something like:No 'plans' proper, but I can change things around if it would be more convenient for this updated layout. We are planning on releasing Alpha 26 in the coming weeks so I'll try to get ahead of that. Will require some synchronisation on our end to update the packages in other repositories but I expect most people will see it as a positive change.
In the end we could have 3 packages:
-
pyrogenesisbinary for each CPU architecture -
pyrogenesis-datacommon data (for any CPU) -
0adthe data of the 0 A.D. game (for any CPU)
I propose to do the reorganisation/renaming upstream for Alpha 26 (or the next one).
The idea is that all GNU/Linux distribution (not just Debian and derivatives) should use the same split with
pyrogenesisand0ad. Or it will confuse users.-
@rousseau Just to add some context about
0ad-data-common, I added that binary package a while ago at the request of the Ubuntu dev who handles the release+nightly Ubuntu PPA builds for 0ad (in an effort to make it easier to package nightly builds). If we end up changing the binary package namespace for 0ad, let's try to not break the PPA workflow as well for our downstream friends. (Also let's avoid changing it at least until after bookworm is released since we're so close to the freeze now and I'd rather not get stuck in NEW during the freeze if possible.)
In the end we could have 3 packages:
-
pyrogenesisbinary for each CPU architecture -
pyrogenesis-datacommon data (for any CPU) -
0adthe data of the 0 A.D. game (for any CPU)
I strongly support this proposal, as it would be a nice incentive to package others games based on Pyrogenesis, in addition to 0 A.D. For Debian users, it might even be an incentive to develop such new games.
-
