Re: Quake packaging
On 02/07/11 23:07, Simon McVittie wrote:
> I've had a look at quake and quakespasm, and in general they look good.
> Thanks for working on these!
>
> I've pushed some proposed changes to a branch called "smcv" in each
> repository: feel free to merge or reject them. There are some other things
> that should be addressed before upload, listed below.
Thanks for all your work! Amazing.
I've merged all your changes and pushed to master, along with a few
trivial tweaks.
> Both packages
> =============
>
> In my branches I changed the target distribution to UNRELEASED, because if
> I'm going to sponsor this, I'll upload directly from pkg-games git, and only
> push the change from UNRELEASED to unstable when I have actually uploaded.
Hmm, I don't really understand what it means to upload directly from
pkg-games git, but if it works it's no problem for me.
> Do you intend these packages to be games-team-maintained? (I assume you do,
> since they're in pkg-games git.) If so, the games team should be in Uploaders
> to signal that (or if you don't want to be the primary maintainer, make
> the games team the Maintainer and move yourself to Uploaders).
Yep - added games team to Maintainer in both packages.
> Feel free to add me to Uploaders too, if you want an "official" co-maintainer.
Also done.
> quake
> =====
>
> Fixed in my branch
> ------------------
>
> In my branch I moved it to contrib/games, because this package is specifically
> for the id Software game; if we packaged OpenQuartz (which, to be honest,
> I probably wouldn't bother with), it should have its own menu entry and
> launcher, live in /usr/share/games/openquartz, and not provide quake-data.
> (It's not Quake, but a remarkably similar game called OpenQuartz, as far
> as I'm concerned.)
Ack.
> I added g-d-p as an alternative to quake-data in the dependency; the
> ftpmaster who reviewed quake3 (I forget who now) suggested that, as a
> way for new users to "bootstrap" the data. Doing that requires that the
> menu entry does something fairly sensible when the data is missing, but you
> took my need-data.sh from quake3, so that's already covered.
Also ack.
> The other changes in my branch are hopefully self-explanatory.
Yep, that all seems sensible. Have merged it all.
The xmlstarlet stuff with the icon gave me a real smile when I saw it,
very ingenious. :)
Just out of interest, what's the benefit to shipping the multiple sizes
of icon? I figured that most environments would just scale down the
large one. (Ideally I would have preferred to ship only the single SVG
in the _binary package_, but I didn't have the source for the old icon.
But there's probably a reason not to do that.)
> Unaddressed
> -----------
> I'm not sure whether the quake-data virtual package really makes sense
> or not: I'm be tempted to depend on
> quake-registered | quake-shareware | game-data-packager directly.
Merged. I don't really understand the ins and outs of this.
> I don't have either of the mission packs myself, so I don't know how they
> work. If you launch a game of vanilla Quake, can you "upgrade" to a
> mission pack through the GUI (like you can click on Team Arena or use the
> Mods menu in Quake 3), or do you have to run the engine with a command-line
> option?
Definitely in the original engine and also in Quakespasm you have to
re-run the engine and change it on the command line.
Darkplaces might be different, not sure.
> If you need a command-line option, the packages produced by g-d-p should
> probably be called quake-armagon-data and quake-dissolution-data, and the
> quake source package should produce quake-armagon and quake-dissolution
> binary packages (similar to quake) with a .desktop and .menu that use
> the appropriate option.
This would make it more consistent, although I think anyone who has the
mission packs likely knows about -rogue, -hipnotic and such. I can
definitely put the appropriate packages in 'quake' package, but I guess
the binaries and menus would always end up installed, even if the user
did not have those data packages installed?
> Is there any particular reason why you chose GPL-3+ for the packaging?
> If you don't have a strong objection to the GPL-2, I'd prefer it if
> the packaging was under a license at least as permissive as Quake itself
> (i.e. GPL-2+): this package is conceptually Quake, even though it doesn't
> contain anything under id copyright.
There wasn't really any reason, I just chose the "latest version".
As a result I relicensed my stuff to GPL-2 and removed your exemption
from debian/copyright in the 'quake' package, since all are now covered
by the same license.
> The "Files" stanza for your own copyright should have an explicit license
> statement (something like the "Permission is granted..." blurb for
> need-data.sh, or the FSF-recommended "This program is free software..." blurb
> as used in openarena), even though the full license is included
> by-reference anyway.
Fixed after merging your changes. :)
> The "Files" stanza for quake.png needs a verbatim copy of the
> license statement from wherever you got it (judging by its style and copyright
> holder, presumably it's from some sort of "extra Tango icons" package?),
> and preferably a URL or explanatory text for where you got it from. If
> it's really GPLv2-only, that makes me sad, but there's nothing we can do
> about that.
That icon is gone now. FWIW, I got it from here:
http://tango.freedesktop.org/User:Dobey
> quakespasm
> ==========
>
> Fixed in my branch
> ------------------
>
> I changed the target distribution to UNRELEASED, because if I'm going to
> sponsor this, I'll upload directly from pkg-games git, and only push the
> change from UNRELEASED to unstable when I have actually uploaded.
Ack
> I flattened the two changelog entries into one, since its history before
> the initial release to Debian isn't interesting for Debian.
Agreed.
> As in quake, stanzas in debian/copyright should have a verbatim copy of the
> license statement. All files in quakespasm seem to be the same (modulo
> whitespace), so I added one.
>
> The other changes in my branch are hopefully self-explanatory.
Seems all good.
> Unaddressed
> -----------
>
> I notice that quakespasm uses ~/.quakespasm, not ~/.quake. This means that
> if we ever decide to make quake use a different engine, everyone doing an
> upgrade will "lose" their settings and savegames, which would be unfortunate.
> Possibly we should add a way to override SYS_USERDIR via the command
> line (can Q1 cvars be command-line-only like they can in Q3?) or an
> environment variable (if in doubt, this is safer), and make quake
> specifically use ~/.quake?
Yeah, that's a good point. I'm not sure if savegames would generally be
cross engine compatible. (/me looks at the format) Actually since it's
all text it might be OK.
It's likely that config.cfg files would be mostly cross engine
compatible, especially for people who write their own in a text editor
or whatever, and there is a 'base set' ie that which the original engine
supported. However most engines will simply dump out all their
variables to config.cfg when exiting, including engine specific ones. I
seem to remember Darkplaces config.cfg files can get quite hairy.
So yeah... I agree we can probably get a nicer behaviour than just plain
losing all of your settings when you change engine. However it might
lead to some unpredictable circumstances. Technically it would be a
simple patch.
> Are we considering quakespasm to be something that users should never run
> directly? If so, it shouldn't be in $PATH. (This is probably not the case,
> though, particularly if our justification for it being in main is the
> existence of OpenQuartz.)
No, I think it's fine to run directly.
> Judging by the comment at the top of snd_mp3.c, it's likely to have copyright
> holders whose copyright notices haven't been preserved (the authors of
> libid3tag). This is a GPL violation, strictly speaking... to be safe,
> we should assume that every copyright holder of libid3tag might be a
> copyright holder on that file, and add appropriate notices. Doing that
> as a patch would be fine, I think.
I saw you did this now - amazing work, thank you so much. :)
One question:
I saw you added quakespasm-dbg package, which was spitting out some
lintian warnings about priority and section. I have made it Section:
debug, Priority: extra. However it still doesn't actually do anything
so it produces an empty binary package. Would you like me to implement
this, or are you planning to do it?
Thanks again for all your help!
Cheers,
David
Reply to: