Re: Proposed changes to wesnoth-1.16
On Wed, 17 Jan 2024 at 10:02:25 +0100, Rhonda D'Vine wrote:
> So unfortunately the only way forward I see right now is this suggestion:
> ditch the -core package all together, because adding recommends to the -core
> package defeats the purpose of it. And change the depends to recommends in the
> main package. The way that recommends are installed by default in most package
> frontends offers both approaches I guess, turns it into an opt-out for the
> campaigns instead of the current opt-in approach. And given that the way
> appstream metainfo data works doesn't offer us much other possibilities I guess
> that would be the way forward.
It's possible for AppStream metadata (appdata/metainfo) to declare that
it's an addon for another AppStream object. Would that be any help?
So you could have something like this:
- wesnoth-x.y-core Recommends one or more "default" campaigns, whatever
that might mean (including whichever one you would recommend to a new
player), and contains the executable, .desktop file, and AppStream
metainfo;
- each of the other campaigns Depends on wesnoth-x.y-core, and has
AppStream metainfo that says "I'm an addon that extends
org.wesnoth.Wesnoth-1.16.desktop", but probably no .desktop file
That would be similar to the way that games with free or paid DLC are
presented on Steam, if you're familiar with that - just installing the
game will give you some default set of content, but then the extras
are also listed as a sub-product of the game which you can download
separately. That's usually because it costs extra money, but sometimes
the DLC has no additional cost, and is just listed separately because
it costs extra disk space and not everyone will want it.
That seems a good model for a game with multiple campaigns? Some basics
are built-in, and the rest are "free DLC"?
I do notice, though, that Wesnoth itself is listed on Steam, and does not
have any DLC available there - which presumably means that the single
monolithic product that's listed on Steam is the equivalent of our
metapackage, and includes all official campaigns as non-optional. Are
they really so large that this complexity is worth it to be able to
exclude them?
For a real example of this use of AppStream addons within Debian, search
for Retroarch in GNOME Software, and you'll see that individual "cores"
(emulation backends) like mGBA and DeSmuME are listed as "Add-ons". (For
me, each one is listed 3 times... welcome to unstable.)
smcv
Reply to: