On 05/11/2016 05:34 PM, Austin English wrote:
> On Wed, May 11, 2016 at 3:47 AM, Tobias Frost <t...@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
