Re: Proposed changes to wesnoth-1.16
On 2024-01-12 at 01:19, Vincent Cheng wrote:
> On Thu, Jan 11, 2024 at 7:25 AM P. J. McDermott <pj@pehjota.net> wrote:
> > dpkg-source will ignore but also complain in the build log about every
> > single removed file, but otherwise sure, that works. To be clear,
> > you're not convinced repacking is necessary, but you'd be OK with
> > removing the Lua ECC in the clean target? Or you're not convinced
> > either is necessary?
> >
> > I certainly don't trust the build system, because there's currently
> > nothing *to* trust. Wesnoth 1.17/1.18's build systems (CMake and SCons)
> > don't even have an option to use a system copy of Lua 5.4.
>
> Yep, please go ahead and remove embedded code copies with d/rules
> clean. This is also what I do with other packages that I maintain
> where upstream's build system doesn't give me the flexibility of not
> using embedded code copies, e.g. supertuxkart [1].
>
> [1] https://sources.debian.org/src/supertuxkart/1.4%2Bdfsg-3/debian/rules/
Thanks for confirming.
> > So since Lua compiled as C++ isn't (yet) universal among distributions
> > or Lua itself, and Wesnoth still wants some compile-time changes,
> > upstream might not be willing to support using system Lua (even though
> > they did before 1.9.0), especially this late in their development cycle
> > while they're understandably focused on getting a release ready. But
> > I've developed and submitted [9] a patch series to add support to both
> > build systems for using system Lua 5.4 C++ on non-Windows platforms.
[...]
> > [9]: https://github.com/wesnoth/wesnoth/pull/8234
>
> I'm happy to defer to what you think is best here - whichever approach
> you think is more maintainable, whether it's to hack around the build
> system with d/rules or add the patch series that you linked above (I
> guess that kind of depends on how likely you think the patch series
> would be accepted upstream - I wouldn't really want to carry it around
> indefinitely).
My pessimism was perhaps premature; I'm getting a more positive response
upstream to my potentially controversial and close-to-RC-version patch
series than I expected, so we'll see how that goes.
If I add a series of related patches, for example this series of eight,
I think they should go in a subdirectory of debian/patches/ to keep
things better organized, unless you disagree.
> > > The plan sounds fine to me, thanks for volunteering to tackle this!
> > > I'm happy to sponsor/upload wesnoth when it's ready, feel free to ping
> > > me and I'll try to get back ASAP.
> >
> > Thanks for sanity checking the plan and for the sponsorship offer! When
> > I have things ready to upload, should I send mail To: you and Cc: the
> > list or just send To: the list? I'm asking what's more convenient for
> > you, in case you filter and don't always read list mail but do read mail
> > sent To: you.
>
> Mail sent directly to me will get my attention faster, but I'll try to
> be better about responding to mail both on and off list.
OK, I just thought I'd ask in case you don't have time to read the
list or prefer to not get duplicate messages. (Too bad SmartList
isn't as "smart" as GNU Mailman's "Avoid duplicate copies of messages"
option.)
> > And, do you have any thoughts on the campaigns dependency/AppStream
> > bug [11]? The issue is that wesnoth-1.16-core provides the executable
> > and therefore also the .desktop and .appdata.xml files, but since
> > the campaigns are split out into individual packages and only the
> > wesnoth-1.16 metapackage depends on them, users only get the executable
> > without any campaigns when installing through "software center" package
> > manager frontends that find application packages via AppStream data.
> >
> > Rhonda suggested some kind of manual AppStream data adjustments, but I
> > can't find anything in the AppStream specification about adding package
> > dependencies or anything else relevant, so I don't know what she means.
> >
> > Would you object to making wesnoth-*-core recommend all the campaign
> > packages? I found a package in Debian with AppStream metadata and
> > Recommends and tested that gnome-software with default APT configuration
> > does indeed install the Recommends packages. Or do you have any other
> > suggestions?
> >
> > [11]: https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/2033222
>
> I don't really have any context into how appstream or Ubuntu software
> center works, again happy to defer to what you or Rhonda think is best
> here.
Yeah, I also am inexperienced with AppStream and "software center"
things. Fortunately I have a Debian system lying around that came with
gnome-software installed, so I confirmed that GNOME Software (which uses
PackageKit which uses APT) would indeed install Recommends packages as
APT itself does by default. (I also learned that Ubuntu Software Center
was discontinued and replaced with GNOME Software in 2015.)
> I'm fine with having -core recommend all the campaign packages.
Thanks, so unless Rhonda clarifies and suggests otherwise, I'll go with
Recommends.
--
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: