Re: Proposed changes to wesnoth-1.16
On 2024-01-17 at 10:02, Rhonda D'Vine wrote:
> * P. J. McDermott <pj@pehjota.net> [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.
--
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: