Re: Updating Minetest to 5.5
On Fri, 25 Feb 2022 at 07:29:48 +0100, Markus Koschany wrote:
> You probably don't need a new source
> package just for the irrlicht fork if minetest is the only "consumer"
Expanding on that, I have some questions I want to ask:
* Is any other package in Debian likely to depend on Minetest's fork
of irrlicht?
* Does Minetest's fork of irrlicht have a stable API?
If the answer to either of those is no, and especially if the
answer to *both* is no (as I suspect), then I think packaging
Minetest's fork of irrlicht as part of the minetest source package (a
vendored/bundled/embedded copy), and most likely linking it into minetest
statically, would actually be *better* than packaging it separately. If
Minetest upstream release them together, then just don't remove it;
if Minetest upstream release them separately, dpkg source format 3.0
(quilt) can deal with combining multiple upstream tarballs into one
source package.
When we package libraries as separate packages, we do that in order to
get the benefits of being able to share them between multiple library
users, but there is a packaging and coordination cost in having more
source packages to deal with.
If you're packaging minetest and irrlicht-minetest as separate source
packages, then I'm concerned that you'll be paying the cost of a
separately-packaged library, without actually getting any of the benefits!
Obviously it would be preferable if minetest could use the packaged
version of upstream irrlicht, but if that's not an option because their
irrlicht is not compatible, then proliferating packages is not actually
helping us. If we compare the possible setups with bundled and separate
irrlicht:
* bundled:
src:irrlicht
src:minetest (contains patched irrlicht)
src:supertuxkart (contains patched irrlicht)
* separate:
src:irrlicht
src:irrlicht-minetest (is a patched irrlicht)
src:irrlicht-supertuxkart (is a patched irrlicht)
src:minetest (requires irrlicht-minetest)
src:supertuxkart (requires irrlicht-supertuxkart)
then you'll notice that in each case, fixing a security vulnerability in
irrlicht would require three uploads - so packaging each fork separately
would not actually reduce the security team's work at all.
The yquake2 source package is an example of combining multiple upstream
tarballs, if you need one (upstream does separate releases of the game
engine and the CTF plugin, but the proprietary patch data managed by
game-data-packager includes the CTF game-mode, so being able to install
the engine without the CTF plugin seemed like it would just create a
broken situation for no real benefit).
smcv
Reply to: