Re: Proposed changes to wesnoth-1.16
Hey. :)
* P. J. McDermott <pj@pehjota.net> [2024-01-16 19:25:27 CET]:
> On 2024-01-16 at 15:31, Rhonda D'Vine wrote:
> > Yeah - don't be so pessimistic about wesnoth upstream. They are pretty
> > awesome on many levels and where a charm to work with over the years, even
> > decades now. :)
>
> So it seems. :) I guess I'm used to upstreams who are hostile to
> somewhat large patch series that add more build configurations that need
> tested just to satisfy a distribution (7kaa for example rejected most of
> a patch series to support system libuuid).
Potentially I wouldn't call it "hostile" if people refrain to take larger
series later in the release cycle per se, but I get what you mean. You'll
never know. Different people also have different (and difficult) days at times
which might make them react differently. Trying usually never hurts, but you
can get used to certain people over time to work with them better when you
understand their approaches to things. :)
> > if you want to organize them better, sure. If they are not meant to stay
> > around because they were taken from upstream and will vanish with next stable
> > release I guess it's not worth the effort, but it doesn't hurt there neither.
>
> Not much effort to add a "/" to patch names: "quilt new 05foo/01bar" or
> "quilt import -P 05foo/01bar foo-bar.patch".
Right. :)
> > For me also the Cc was extremely helpful to notice it. I am slowly trying to
> > get back into things, but digging in mailinglists often enough is costing too
> > much energy for too little benefit.
>
> OK, good to know. I've seen some people ask not to be Cc:ed.
Yes, I know that. It might be a neurodivergent thing, or general stress, some
people have different approaches to workflows. In general though, when you
send it to the list and don't receive a response from someone you would in
general expect a response it can't hurt too much, but that might be just me.
> > I'm inexperienced too, but there must be a way for gnome-software to select
> > which packages to offer. My first thought went to listing packages with a
> > .desktop file. And I'd try moving that to the main package.
> >
> > There is a reason the -core package does not depend on the campaigns, and I
> > really would love to avoid to suddenly dropping all the campaigns on users of
> > the package. Newly added recommends would get pulled in on upgrade from what I
> > know, by default in apt & co, so I really really would love to have such a move
> > avoided.
>
> Ah...
>
> I did first consider moving the .desktop and .appdata.xml files to the
> wesnoth-BRANCH metapackage, because that's a much cleaner solution.
> But I thought those files were supposed to be in the same package as the
> executable? Otherwise a user could end up with the executable not going
> in their menu. And the only way to get it in their menu would be to
> install the metapackage and all of the campaigns, which defeats the
> purpose of the packaging split.
Yes, that's the tricky part, and from what I digged around yesterday I think
there might not be a different way around: The metainfo and desktop files have
to be with the executable because otherwise like you said it won't appear in
the menu if you just install the package with the executable.
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.
So creating a NEWS entry to explain this move (especially the opt-out instead
of opt-in approach that appstream forces on us), deprecate the -core package as
empty package with a depends on the main one, and changing the Depends in the
main to Recommends for the campaigns would be what I'd suggest to do.
> > I am scanning over the other changes you proposed, and I want to especially
> > thank you a ton for the copyright file one. I tried to tame that beast
> > multiple times and pushed it back from every upload I contributed to since a
> > looong while now because I never managed to wrap my head around completing it.
> > So that is extremely appreciated!
>
> I'm also working on a Perl script to automatically inject into the DEP5
> copyright file all of the image copyright information upstream now
> conveniently provides[1][2] in 1.17/1.18!
>
> This however adds a Perl package dependency that maintainers will need
> when running debian/branchcheck, so I'll add a note to branchcheck
> and/or debian/README.source.
That would be very fine with me. I think there might be some Build-Depends*
specific entries for that; if not, it doesn't hurt to have them in general
there.
> [1]: https://github.com/wesnoth/wesnoth/raw/master/copyrights.csv
> [2]: https://github.com/wesnoth/wesnoth/pull/7903#issuecomment-1716480463
>
> > About debian/embed.c, this is about a lintian warning that will get fixed in
> > future upstream versions from what I read in your comment, isn't that a bit
> > over the top? :) Don't want to cut your enthusiasm short, just wondering.
>
> Upstream turned out to be a little more reluctant[3] to merge this fix,
> and understandably so especially since I later realized there's a
> possible legal issue[4] with it. I'd like to fix it up-upstream,
> but that involves figuring out how to report a bug against Android
> (requiring a Google account).
>
> I also realized after Vincent merged the change that I broke cross
> builds. It needs to use CC_FOR_BUILD from /usr/share/dpkg/buildtools.mk
> instead of CC. And debian/embed.c computes the checksum incorrectly.
> If the change stays (pending above), I'll fix these issues.
>
> [3]: https://github.com/wesnoth/wesnoth/pull/8171
> [4]: https://lists.debian.org/debian-legal/2024/01/msg00007.html
I am very much impressed by how deeply you invest into this - we need more
people like you :)
Cheers!
Rhonda
--
Fühlst du dich mutlos, fass endlich Mut, los |
Fühlst du dich hilflos, geh raus und hilf, los | Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los |
Reply to: