[Pkg-pascal-devel] Bug#820708: castle-game-engine: hardcoded libpng12 dependency

[Tobias Frost]

Hi Michalis,

Am Montag, den 11.04.2016, 21:53 +0200 schrieb Michalis Kamburelis:
> > Source: castle-game-engine
> > Version: 5.2.0-2
> > Severity: serious
> > Justification: libpng1.6 transition
> > 
> > Dear maintainer,
> > 
> > in the discussion in #820566 it surfaced that castle-game-engine
> > has a hardcoded
> > dependency on libpng12.
> > 
> > After the completion of the tlibpng 1.6 transition, libpng12 will
> > be removed,
> > Therefore this bug is RC.
> > 
> > Another bug is that this dependency is completly oqaue to the
> > outside world.
> > this is why has not been detected during the preparation of the
> > transtiion.
> > Please establish something here to catch e.g by buildtime checks,
> > build-conflicts or other measure to make this more robust for other
> > transitions.
> > 
> > (view3dscene, #820566 has the same bug, maybe you find can together
> > find an solution.)
> 
> 1. 2. are just clarifications (I'm just repeating here some bits
> mentioned in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820566
> ), 3. is a suggestion how to make a buildtime check if someone would
> like to tackle this:)
> 
> 1. Castle Game Engine works with libpng 1.2 or 1.4 (not only 1.2).

We currently have the transition to 1.6 ... But if you are not accesing
libpng's structs data members directly, you are likely to be safe, API
wise. (Said that, I do not have blunt idea how Pascal handles library
and if there any pitfalls).

libpng1.2 will be removed from Debian soon.

> 2. It's not a "hard dependency on libpng". It's perfectly sensible to
> use Castle Game Engine without libpng. Having libpng installed
> *helps*
> (it allows you to open png images, obviously), but it is not required
> for all CGE use-cases. E.g. if you make a game that does not load png
> images, you can certainly use Castle Game Engine without libpng.
> 
>   For Debian packaging, it may make sense to just simplify and say
> "let castle-game-engine recommend libpng". I'm just saying that it's
> not a strict dependency for upstream.

Upstream and distribution requirement might vary here. I understand
flexibility is important for you, but for distributions is like
important to have determinims, avoiding to suddenly change available
features in its software.
The package fails to provide that determinism, even worse, with the new
libpng1.6 in the archives, this will fail silently. 
It was pure luck that we were made aware of this problem, and that is
why I recommend measures to avoid such thing happening again (standard
QM methods; I work in QM)
I think the bug here is a Debian packaging bug, not an upstream one.

I guess the package maintainer wants indeed to add a "Recommends:
libpng16-16" -- as soon as compatibility is verified, maybe along with
some documentation (e.g. in the package description). 

>   Also remember that it will disappear in next CGE release, where PNG
> reader is implemented without libpng (using FPC fcl-image, so it gets
> compiled statically in, with the rest of FPC RTL).

Even better, but the freeze for Stretch is already on the horizon...

> 3. If you want to add an automatic test that CGE can correctly
> read+write PNG files, you can use e.g.
> examples/images_videos/image_convert.lpr . Just compile it, and run
> like
> 
>   image_convert ../2d/box_with_borders.png /tmp/whatever.png
> 
>   If /tmp/whatever.png exists, then png reading+writing works. In
> case
> of problems (like a missing libpng), the program should write a clear
> error message and have non-zero exit status.

That would be also an idea, could be even included in a testsuite /
autpkgtest.

> Regards,
> Michalis

-- 
tobi