Thargoid wrote:Just make the large one conflict with each of the group ones, and the group ones individually conflict with the large one.
I would advise in this case just
having the group ones conflict with the large one (or the other way round, if you think that's easier to maintain). Otherwise you may end up with a case where the dependency check order is:
"component one" rules itself out because it sees "monolithic", and then "monolithic" rules itself out because it sees "component two". "component one" doesn't get re-checked at this point, however, so then "component two" rules itself out because it doesn't have "component one" which it requires.
As far as separating goes ... I wouldn't generally advise it unless:
- You have a clear separation of functionality between components so you can usefully install only some (e.g. "Povray Planets" or "Your Ad Here!")
- You want to separate assets and config (e.g. "Griff's Shipset"), because you expect the config to change more frequently than the assets and don't want to force a redownload of the assets every time, or because you want to have multiple configs for the same assets - in that case, the config should depend on the assets, and the assets could add the config(s) to their optional list
Remember that people can still download and install an OXZ file with a web browser and drop it into their AddOns folder and it's still a bit easier - except on a Mac - than using the OXP format. If the OXZ manager has problems with large files, and they aren't fixable, that might be a better workaround. (If you try it, you'll see that the OXZ manager then highlights that OXZ red for "manual install" but still shows you if new versions are available)
Maybe if I get round to adding a bit more dependency helpfulness to the OXZ manager - you install an OXP and if after downloading the dependencies aren't met it offers to go and fetch them right then - it might matter less, but there are tricky things to adding that sort of extra functionality, so not for 1.80.