Re: Proposed changes to wesnoth-1.16
On 2024-01-18 at 13:32, Simon McVittie wrote:
> On Thu, 18 Jan 2024 at 05:57:43 -0500, P. J. McDermott wrote:
> > <id>org.wesnoth.Wesnoth-1.16-httt.desktop</id>
>
> I don't think the ID for new components should end with .desktop,
> particularly if the package doesn't (and won't) ship a .desktop file of
> that name.
>
> Ideally this would be happening in consultation with upstream, because
> it's the upstream that owns the namespace, and Appstream is generally an
> effort that encourages "upstream first" development.
Right.
> > <metadata_license>GPL-2.0-or-later</metadata_license>
>
> I don't think Appstream allows this license for the metadata, because
> metadata for all packages gets bundled together into one large index,
> and with copyleft licenses it wouldn't be obvious that it's legally
> valid to do that (imagine trying to build an index where one package's
> metadata is GPL-2.0-only, another is GPL-3.0-or-later and a third is
> CDDL or something, and then ask yourself what license would be valid
> for the combined work). There's a short list of permissive licenses that
> are allowed, with FSFAP suggested. See:
> https://freedesktop.org/software/appstream/docs/chap-Quickstart.html
Right, makes sense. I was thinking that the metadata (name, summary,
and description) might come from GPL-2+ markup files in the source. In
other words, my focus was on the inbound side of the license rather than
the outbound.
> > > 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.
>
> If there is a campaign that you (or upstream) would recommend as "if
> you only play one campaign after finishing the tutorial, it should be
> this one", then I would personally include that in the core content too,
> unless its size is prohibitive.
I had considered that. The first/easiest/shortest one after the
tutorial is A Tale of Two Brothers.
> > On amd64, src:wesnoth-1.16/1:1.16.11-1 campaign packages total
> > 191.558 MiB
>
> For perspective, if I try installing the game and all its dependencies
> and Recommends into a minbase-like container (debian:sid-slim), apt tells
> me that the installed sizes of some comparable games are:
>
> - openarena: about 1 GiB
> - 0ad: about 1.5 GiB
> - wesnoth-1.16-core: about 500M
> - wesnoth-1.16: about 900M
Yeah, 0ad-data for example is huge: sixth largest package in Debian
(if the seven versioned linux-image-*-dbg packages are counted once).
Having played it, I'm familiar with and not surprised by its size.
1.5 GiB for 0ad actually sounds like a gross underestimate: 0ad-data's
Installed-Size is 3218736 KiB. But I digress.
> This is double-counting some dependencies like the X11/Wayland libraries,
> which a real desktop user would already have installed, so the first ~ 250M
> of each of those sizes can probably be ignored.
>
> I personally don't think +400M of installed size (200M of compressed
> packages) for a complete set of campaigns is very "expensive" in the
> 2020s.
Actually 191.558 MiB installed as I said, 125.65 MiB downloaded (mostly
images, so package compression yields little). So even less expensive.
The split was done in 2005 when storage media were smaller, but surely
so was Wesnoth's data.
> > Which, if they were all one package, would be in the 99th percentile of
> > largest packages
>
> I'm not suggesting that they need to be all one big package at the
> apt/dpkg level:
It was maybe a slightly bad comparison against other split packages, but
I was responding to your question of the value of being able to exclude
optional campaigns.
> openarena splits up its data packages (originally done so
> that its source packages could fit on CD-ROMs) but they are all mandatory,
> and from an end-user perspective, the only options that make sense are
> "install OpenArena" or "don't".
Yeah, I've played through OpenArena to the end (thanks by the way! still
a fun game), and the way the levels unlock tiers, I don't think the game
would function if they weren't all installed. In Wesnoth everything's
unlocked, so you could play just your favorite campaigns, start with the
hardest, play the story out of order, etc.
> Being in the 99th percentile isn't necessarily a problem, in any case:
> this is a game, not a typical package like a utility or a library, so
> it's expected that its data package(s) is/are quite large.
Indeed. Unsurprisingly, even just the number of data files (18,379 in
upstream Git) is somewhat large relative to a typical package (which
will result in one of Debian's larger copyright files, over 11,000
lines, but still tiny compared to src:boost1.83's 49,514 lines).
> For Wesnoth campaigns, I'd probably suggest Recommends over Depends,
> so that users who care enough about disk space can remove them if they
> want to.
Yes, the plan Rhonda proposed[1], with which I agreed, does this and is
much simpler than producing 19 new metainfo files upstream (especially
with my plan to parse existing metadata and translations).
As I said before, it seems like a decent compromise for users, changing
from opt-in to opt-out to make installation more reliable but still
leave the option to exclude campaigns if desired.
Certainly under current time constraints (upstream busy working to
release a new beta version in just a few days, on the road toward a new
stable version, plus time in NEW potentially coming close to Ubuntu's
Debian Import Freeze), that seems the most viable.
Barring objections, I'll go ahead with that as previously planned/
agreed.
[1]: Message-ID: <[🔎] ZaeXoSsrE0y7KfNF@mirage.deb.at>
> > 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.
>
> Right - to me, that suggests that putting a lot of effort into making
> the campaigns not be installed by default is not necessarily worth it,
> and not installing them by default might even be a net negative.
The status quo does result in confusion (demonstrated by the Launchpad
bug[2]) for at least players who install via AppStream-based systems,
though this is a solvable problem, given enough effort.
[2]: https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/2033222
> > 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?
>
> This might be a new feature in testing/unstable, I don't know.
By "small screen" I mean specifically a phone (where the bookworm system
I installed came with GNOME Software and I left it alone). So maybe
GNOME Software's responsive layout hides addons, although that seems
suboptimal.
> > Should desktop application and addon IDs end in ".desktop" or not?
>
> Desktop application IDs: optional. For new products, not adding .desktop
> is preferred, but keeping an existing ID as-is (so that old and new
> versions of the same app have the same ID) is a higher priority than
> canonicalizing it.
>
> Addon IDs: no they should not.
> https://freedesktop.org/software/appstream/docs/sect-Quickstart-Addons.html
>
> > 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?
>
> I would say that by definition, the spec is correct :-)
Oh, the specification is just slightly incomplete in the place I was
looking. Section 2.7.3 simply says[3] <extends> "refers to the ID of
the component this addon is extending", which I assumed to mean always
the <id>. But section 5.2.3 you referenced above says[4] the same plus
"For desktop applications, this is usually the name of their `.desktop`
file". That clarifies it.
[3]: https://www.freedesktop.org/software/appstream/docs/sect-Metadata-Addon.html#tag-extends
[4]: https://www.freedesktop.org/software/appstream/docs/sect-Quickstart-Addons.html#qsr-addon-content
Thanks again!
--
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: