Re: supertuxkart 0.7.3
On Tue, Dec 11, 2012 at 2:31 AM, Jon Dowland <jmtd@debian.org> wrote:
> The issue here is not just the magnitude of work for each approach but
> who does the work. So, embedding irrlicht is less work for the maintainer
> of supertuxkart, but potentially more work for the security team. Patching
I'm the (co-)maintainer of both supertuxkart and irrlicht, and I fully
intend to keep both sets of packages in good condition, and that
includes security support. So no, the security team won't have more
work on their plate, aside from having my packages reviewed and
approved by the security team when issues arise.
I'd like to point out, however, that we're talking about 2 games
packages, not some mission-critical server packages. Irrlicht has only
had a single CVE issued afaik (in 2008). I'm not proposing to embed
zlib/libpng/libxml or the like in stk. In practice, this is unlikely
to cause work for the security team, and it'll end up just being
another line in the security team's list of embedded code copies.
> irrlicht to build separate packages for supertuxkart to build-depend on
> is more work for the maintainer, and potentially less for the security
> team. (I lean towards the former, strongly. Is there any precedent for
> the latter?)
Precedent for the latter, i.e. precedent for embedding forked code in
a package? Sure, there are hundreds of examples [1].
> And every time the supertuxkart-specific bits were modified, all users
> of the other bits would get a new binary package to download and install,
> for no reason.
I've been thinking of splitting up supertuxkart into two separate
source packages (supertuxkart and supertuxkart-data), actually, which
more or less takes care of this problem.
Regards,
Vincent
[1] http://anonscm.debian.org/viewvc/secure-testing/data/embedded-code-copies?view=markup
Reply to: