[pkg-wine-party] Bug#823991: libpng16-16: generates a ton of noisy warnings

[Jens Reyer]

On 05/11/2016 05:34 PM, Austin English wrote:
> On Wed, May 11, 2016 at 3:47 AM, Tobias Frost <tobi at debian.org> wrote:
>> can you provide more information, like the package version of your installed
>> wine?  Did you mix stable and other suites? What are the libpng pacakges you
>> have installed?
>>
>> (We have binNMUed everything depending on libpng12 so it is strange that your
>> wine thinks it is compiled against libpng12)
>>
>> libpng has this version warning for a reason, as until version 1.4 it was possible to
>> directly access struct members, therefore if those structs changed this *could*
>> cause incompatiblities. The newer API forbids that, so this should be safe.
>>
>> However, taking a (very) short glimpse at the wine packages: Maybe I missed it
>> but it seems from there that they do not declare a Depends on the libpng
>> library package.
>> That could be an explanation why it has not been binNMUed, and this would be
>> actually a bug in wine (policy 3.5)
>>
>> CC'ing wine maintainers, maybe they can tell ...
[...]
> I didn't check Debian package, but upstream definitely uses libpng.
> From configure.ac:
> dnl **** Check for libpng ****
> if test "x$with_png" != "xno"
> then
>     WINE_PACKAGE_FLAGS(PNG,[libpng],,[$X_CFLAGS],[$X_LIBS],
>         [AC_CHECK_HEADERS([png.h])
>         if test "$ac_cv_header_png_h" = "yes"
>         then
>             WINE_CHECK_SONAME(png,png_create_read_struct,
>                 [AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include
> <png.h>]],[[typeof(png_set_expand_gray_1_2_4_to_8) *p]])],
> 
> [AC_DEFINE(HAVE_PNG_SET_EXPAND_GRAY_1_2_4_TO_8,1,[Define to 1 if
> libpng has the png_set_expand_gray_1_2_4_to_8 function.])])],
>                 [PNG_CFLAGS=""],[$PNG_LIBS -lm -lz],[[libpng[[0-9]]*]])
>         else
>             PNG_CFLAGS=""
>         fi])
> fi
> WINE_WARNING_WITH(png,[test "x$ac_cv_lib_soname_png" = "x"],
>                  [libpng ${notice_platform}development files not
> found, PNG won't be supported.])
> 
> https://source.winehq.org/git/wine.git/blob/HEAD:/configure.ac#l1590

Thanks for the binNMU request, Tobi!

The Debian packages build-depend on libpng-dev, but indeed currently
there's no runtime dependency in the binary packages (it was there in
wine once, but was lost when the wine-development packaging was merged).

I checked all build-dependencies: many already have matching runtime
dependencies, mostly added by ${shlibs:Depends}.

For the rest (including libpng) I'd suggest to add the following runtime
dependencies as Recommends in libwine.

*Feedback, or better solutions, very welcome!*

* I'd prefer to do this automatically, but am not aware of any
  solution.
  E.g. adding ${shlibs:Depends} and ${so:Depends} to every binary
  package doesn't help at all.
  And debian/scripts/dpkg-depgrep, which is already used to create
  ${dlopen:Depends} with the correct package names of ncurses and
  freetype, doesn't work for all packages (the numbers don't always
  match, see below).

* Only "Recommends", because I'm not sure if they are really needed.
  I've only seen this topic for png/jpeg/tiff before. Not sure if just
  nobody noticed any problem before for the other libraries, or if the
  64-bit libraries work for wine32, too. At least there should be many
  use cases that work without them.

* "libwine" is installed always and on every arch, so it is easiest to
  maintain this awful list there.

Missing/Proposed dependencies:
  libxi-dev,          libxi6
  libxt-dev,          libxt6
  libxmu-dev,         libxmu6
  libxrandr-dev,      libxrandr2
  libxrender-dev,     libxrender1
  libxkbfile-dev,     libxkbfile1
  libxxf86vm-dev,     libxxf86vm1
  libxxf86dga-dev,    libxxf86dga1
  libxinerama-dev,    libxinerama1
  libxcomposite-dev,  libxcomposite1
  libpng-dev,         libpng16-16
  libssl-dev,         libssl1.0.2
  libgsm1-dev,        libgsm1
  libjpeg-dev,        libjpeg62-turbo
  libtiff-dev,        libtiff5
  libxslt1-dev,       libxslt1.1
  unixodbc-dev,       libodbc1
  libcups2-dev,       libcups2
  libdbus-1-dev,      libdbus-1-3
  freeglut3-dev,      freeglut3
  libosmesa6-dev,     libosmesa6
  libgnutls28-dev,    libgnutls30
  libgettextpo-dev,   libgettextpo0

To check the result I first purged all wine and i386 packages on my
amd64 system and then installed the current wine-development. A upgrade
to my proposed version additionally installs the following packages:
  freeglut3:i386
  libavahi-client3:i386
  libavahi-common-data:i386
  libavahi-common3:i386
  libcomerr2:i386
  libcups2:i386
  libgettextpo0:i386
  libgssapi-krb5-2:i386
  libjbig0:i386
  libjpeg62-turbo:i386
  libk5crypto3:i386
  libkeyutils1:i386
  libkrb5-3:i386
  libkrb5support0:i386
  libltdl7:i386
  libodbc1:i386
  libosmesa6:i386
  libtiff5:i386
  libunistring0:i386
  libxcomposite1:i386
  libxinerama1:i386
  libxkbfile1:i386
  libxmu6:i386
  libxrandr2:i386
  libxslt1.1:i386
  libxt6:i386
  libxxf86dga1:i386
Note: only i386 packages were installed, seems for the native arch every
package is already depended on by unrelated packages here. This took
(only) 14MB additonal diskspace, while wine (amd64+i386) with the
current dependencies already consume 660MB.

I assume these build-dependencies don't need a dependency in a binary
package:
  debhelper (>= 9.20151220),
  dh-autoreconf,
  flex,
  lzma,
  bison,
  quilt,
  gettext,
  oss4-dev,
  libxml-simple-perl,
  sharutils,
  pkg-config,
  dctrl-tools,
  khronos-api,
  unicode-data (>= 8.0-1~),
  freebsd-glue [kfreebsd-any],

And finally these build-dependency already have a related runtime
dependency:
  libx11-dev,
  libxext-dev,
  libxcursor-dev,
  libgl1-mesa-dev,
  libglu1-mesa-dev,
  libxml2-dev,
  libpcap-dev,
  libpulse-dev [!kfreebsd-any],
  liblcms2-dev,
  libldap2-dev,
  libopenal-dev,
  libmpg123-dev,
  libasound2-dev,
  libncurses5-dev,
  libfreetype6-dev (>= 2.5.1),
  libfontconfig1-dev,
  libgstreamer-plugins-base1.0-dev,
  ocl-icd-opencl-dev,

Greets everyone
jre