Packaging changes for 1.14.10 and 1.15.3
Moderator: Forum Moderators
- Pentarctagon
- Project Manager
- Posts: 5586
- Joined: March 22nd, 2009, 10:50 pm
- Location: Earth (occasionally)
Packaging changes for 1.14.10 and 1.15.3
As of #4446, which was merged into 1.15 and backported to 1.14, a new column will be populated by wesnothd for clients that connect to the official multiplayer server. The motivation for this change is that a question has come up during discussions more than once regarding how many players get Wesnoth from one source vs another - SourceForge, Steam, software repositories, etc - and this would be able to provide us some actual data to look at (at least as far as players who use the official multiplayer server).
The value that is to be stored for the client's source is read from the file
During packaging, please create the
The value that is to be stored for the client's source is read from the file
<root wesnoth directory>/data/dist
. If the file is not present, or contains an invalid value, then the value of Default
will be sent to wesnothd. The list of valid values is:
- Default
- Steam
- SourceForge
- Flatpak
- macOS App Store
- Linux repository
- iOS
- Android
- BSD repository
During packaging, please create the
data/dist
file with the appropriate value 99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
take one down, patch it around
-2,147,483,648 little bugs in the code
Re: Packaging changes for 1.14.10 and 1.15.3
Suggest to add
Other
as a valid value.- Pentarctagon
- Project Manager
- Posts: 5586
- Joined: March 22nd, 2009, 10:50 pm
- Location: Earth (occasionally)
Re: Packaging changes for 1.14.10 and 1.15.3
That's basically what
Default
covers, though - any situation where the provided options are missing, invalid, or don't apply.99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
take one down, patch it around
-2,147,483,648 little bugs in the code
Re: Packaging changes for 1.14.10 and 1.15.3
That's not going to work well. Packagers won't know about this unless some drastic measures like build failure happen without them setting this. We don't have contact to them, nor do I expect them to read this topic. To make matters worse, while @Packagers are pinged upon tagging,I remember no release where our Debian packager was pinged – the only Linux packager I know of to be in the chat.Default
…
Linux repository
…
Archlinux for example is setting the location of manpages explicitly. That dates back to a bug in the cmake script in 1.8 — a decade ago.
Assuming Linux/BSD repository as default is more realistic – all the other channels we have control over.
Try out the dark board theme.
- Pentarctagon
- Project Manager
- Posts: 5586
- Joined: March 22nd, 2009, 10:50 pm
- Location: Earth (occasionally)
Re: Packaging changes for 1.14.10 and 1.15.3
Yeah, that's a fair point. I was thinking that wouldn't cover people who self-compile, for example, but the number of people who do that on Windows/macOS is probably very small.
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
take one down, patch it around
-2,147,483,648 little bugs in the code
Re: Packaging changes for 1.14.10 and 1.15.3
Is it a problem when packagers don't change the default? I mean, we'd still know that "Linux repository" means "distribution whose maintainer does trigger this", and "Default" is "self-builders and distributions whose maintainers don't trigger this".
- Pentarctagon
- Project Manager
- Posts: 5586
- Joined: March 22nd, 2009, 10:50 pm
- Location: Earth (occasionally)
Re: Packaging changes for 1.14.10 and 1.15.3
According to Iris (from Discord):
So I'll probably open up a FR or a bug for Arch once 1.14.10 gets released. I'm not planning on hunting down the maintainers of other distros further though.Iris wrote:Pentarctagon: I'm pretty sure Rhonda handles both Debian and Ubuntu
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
take one down, patch it around
-2,147,483,648 little bugs in the code
Re: Packaging changes for 1.14.10 and 1.15.3
You could send an e-mail to packagers. See https://repology.org/project/wesnoth/versions for a list
- Pentarctagon
- Project Manager
- Posts: 5586
- Joined: March 22nd, 2009, 10:50 pm
- Location: Earth (occasionally)
Re: Packaging changes for 1.14.10 and 1.15.3
I mean, even based on that list, the large majority are either Debian, Ubuntu, Arch, or don't have any maintainer information listed there.
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
take one down, patch it around
-2,147,483,648 little bugs in the code
Re: Packaging changes for 1.14.10 and 1.15.3
Author of the unofficial UtBS sequels Invasion from the Unknown and After the Storm.
- Pentarctagon
- Project Manager
- Posts: 5586
- Joined: March 22nd, 2009, 10:50 pm
- Location: Earth (occasionally)
Re: Packaging changes for 1.14.10 and 1.15.3
Well, I guess I'll just use that then
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
take one down, patch it around
-2,147,483,648 little bugs in the code
Re: Packaging changes for 1.14.10 and 1.15.3
Rhonda can configure her IRC client to highlight on
@Packagers
. It's pretty easy to do this in most clients.-
- Inactive Developer
- Posts: 503
- Joined: April 24th, 2016, 4:18 pm
Re: Packaging changes for 1.14.10 and 1.15.3
In my experience, there is no way to ensure all packagers get notified _and_pay_attention_.
I'm in the "make it a build error" camp. Sure, that means everyone, not just packagers, have a new step, but the other choice is to set a default. Setting a default means it'll never be changed. Which is the same as not bothering with the feature at all.
I'm in the "make it a build error" camp. Sure, that means everyone, not just packagers, have a new step, but the other choice is to set a default. Setting a default means it'll never be changed. Which is the same as not bothering with the feature at all.
I forked real life and now I'm getting merge conflicts.
- Pentarctagon
- Project Manager
- Posts: 5586
- Joined: March 22nd, 2009, 10:50 pm
- Location: Earth (occasionally)
Re: Packaging changes for 1.14.10 and 1.15.3
Given the position packagers are in, I'd expect that making it an error to not have a value set would simply be patched out anyway.
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
take one down, patch it around
-2,147,483,648 little bugs in the code