Re: Proposed changes to wesnoth-1.16

On 2024-01-17 at 10:02, Rhonda D'Vine wrote:
> * P. J. McDermott <[email protected]> [2024-01-16 19:25:27 CET]:
> > 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. :)

Yes, "hostile" was too strong a word for how I meant to describe a
reasonable position.

> > 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.

Yes, that sounds like the best solution (or the least bad compromise for
users).

I wouldn't blame AppStream for this, because declaring dependencies
is out of the specification's scope (and would make the metadata more
distribution-specific).

> > >  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 adds 10601 lines to debian/copyright, heh.  Which is pretty good
for documenting currently 18379 files.  (Each directory has a reference
count of license/comment stanzas, to figure out when to use wildcards to
merge directory subtrees.)

> > 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.

There's unfortunately no place to declare development dependencies
separately from build dependencies.  Putting it in B-D(-I) helps a
maintainer who uses mk-build-deps or "apt-get build-dep", but not one
who does all their builds in sbuild etc.  It also makes sbuild, buildd,
etc. install a little more than necessary, but that's a minor issue.

And given the choice of B-D or B-D-I (neither of which is semantically
right for this), I assume the latter would be better, to not hamper
architecture porters.  debian/copyright needs to go in arch:any packages
too, but this isn't really a build dependency.  Should I use B-D-I and
debian/README.source then?

> > [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 :)

Aww, thanks!  I'm yak shaving quite a bit at this point.