Re: Proposed changes to wesnoth-1.16
On 2024-01-18 at 00:28, Simon McVittie wrote:
> 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;
wesnoth-x.y-core contains[1] the executable, .desktop file, and
AppStream metainfo and Depends[2] on wesnoth-x.y-data which includes[3]
the tutorial campaign and World Conquest (which is actually a multi-
player "era", not a single-player campaign). So this is done.
[1]: https://salsa.debian.org/games-team/wesnoth/-/blob/140bb5d5/debian/wesnoth-BRANCH-core.install.in
[2]: https://salsa.debian.org/games-team/wesnoth/-/blob/140bb5d5/debian/control.in#L61
[3]: https://salsa.debian.org/games-team/wesnoth/-/blob/140bb5d5/debian/wesnoth-BRANCH-data.install.in
> - 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
Oh, so if wesnoth-1.16-httt contains this addon[4] metainfo file (which
I just wrote and which may not be correct, so corrections welcome), it
will appear on the "Battle for Wesnoth 1.16" page for users to easily
install it alongside the game itself?
<?xml version="1.0" encoding="UTF-8"?>
<component type="addon">
<id>org.wesnoth.Wesnoth-1.16-httt.desktop</id>
<extends>org.wesnoth.Wesnoth-1.16.desktop</extends>
<name>Heir to the Throne</name>
<summary>"Heir to the Throne" official campaign for Wesnoth (branch 1.16)</summary>
<description>
<p>
Fight to regain the throne of Wesnoth, of which you are the legitimate heir.
</p>
<p>
(Novice level, 23 scenarios.)
</p>
</description>
<metadata_license>GPL-2.0-or-later</metadata_license>
<project_license>GPL-2.0-or-later</project_license>
</component>
That should work perfectly then. I'll see if I can write (another)
script to generate these for all (16 in 1.16, 17 in 1.17/1.18)
campaigns. And the wesnoth metapackage should have one as well to
quickly install all the campaigns at once.
Thanks Simon for another great tip!
[4]: https://www.freedesktop.org/software/appstream/docs/sect-Metadata-Addon.html
> 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.
I'm familiar with the DLC concept, though I've never used Steam or the
like.
> That seems a good model for a game with multiple campaigns? Some basics
> are built-in, and the rest are "free DLC"?
Right now, as I said, only the tutorial is built in.
> 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?
On amd64, src:wesnoth-1.16/1:1.16.11-1 campaign packages total
191.558 MiB:
$ wget -q -O - https://deb.debian.org/debian/dists/unstable/main/binary-amd64/Packages.xz | unxz 1>Packages
$ sed -En -- '/^Package: wesnoth-1.16-.*$/{
> /^Package: wesnoth-1.16-(data|core|music|server|tools)$/!{
> : l;
> n;
> /^Installed-Size: /!b l;
> s/^Installed-Size: //p;
> };
> };' Packages | awk 'BEGIN { sum = 0; } { sum += $1; }
> END { printf("%d KiB, %f MiB\n", sum, sum / 1024); }'
196155 KiB, 191.558 MiB
Which, if they were all one package, would be in the 99th percentile of
largest packages (only 303 of 70,146 packages are larger):
$ sed -En '/^Package: /{
> /^Package: wesnoth-1.16-(data|core|music|server|tools)$/!{
> s/^Package: //;
> h;
> : l;
> n;
> /^Installed-Size: /!b l;
> s/^Installed-Size: //;
> G;
> s/\n/\t/;
> p;
> };
> };' Packages | sort -nr | awk 'BEGIN { p = 0; n = 0; }
> { if ($1 < 196155) { ++p; } ++n; }
> END { printf("P = %d, N = %d\n%dth percentile\n",
> p, n, p / n * 100); }'
P = 69843, N = 70146
99th percentile
So... probably worth it? It does however look like 92% (518/562, most
but not all) of popcon[5] users install the wesnoth-1.16 metapackage
instead of just wesnoth-1.16-core and à la carte campaigns. (Why do
some people install wesnoth-1.16-data without wesnoth-1.16-core?)
[5]: https://qa.debian.org/popcon.php?package=wesnoth-1.16
> 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.)
I don't see this if I view com.libretro.RetroArch details in GNOME
Software on bookworm, but maybe just because I'm looking at it on a
small screen, so addons are excluded from the details?
com.libretro.RetroArch.appdata.xml contains:
<id>com.libretro.RetroArch</id>
<launchable type="desktop-id">retroarch.desktop</launchable>
And libretro-mgba.metainfo.xml contains:
<id>libretro-mgba</id>
<extends>retroarch.desktop</extends>
Should desktop application and addon IDs end in ".desktop" or not?
And AppStream says <extends>[6] refers to the <id>, but <extends> in
libretro-mgba.metainfo.xml apparently refers to a <launchable> of type
"desktop-id"? Which is correct?
[6]: https://www.freedesktop.org/software/appstream/docs/sect-Metadata-Addon.html#tag-extends
--
Patrick "P. J." McDermott: http://www.pehjota.net/
Lead Developer, ProteanOS: http://www.proteanos.com/
Founder and CEO, Libiquity: http://www.libiquity.com/
Reply to: