On 27/05/14 01:43, Jamin Hoggard wrote: > Details: > libgtk-3-dev depends on libglib2.0-dev, which depends on libpcre3-dev. > However, libpcre3-dev depends on libpcrecpp0, which introduces > dependencies on C++ libraries (libstdc++).
These libraries must be installed during compilation due to the way libpcre is packaged, but do not introduce extra dependencies for applications compiled against Gtk3 (for instance, gnome-terminal uses Gtk3 but does not depend on libpcrecpp0, even indirectly). So, the impact is "developers' systems have slightly more libraries installed". The build-essential metapackage depends on a C++ compiler (and hence libstdc++) anyway, so this has basically no effect on the build-dependencies of any Debian package (libpcrecpp0 itself is small). Is there a concrete situation in which it is a practical problem that a developer's system must have libpcrecpp0 and libstdc++? If there is a real practical problem, splitting libpcre3-dev into C and C++ parts is likely to be a better solution. However, libstdc++ is used by build-essential and apt, so this seems likely to be mostly a theoretical concern: in practice, Debian systems in general, and developer systems in particular, are going to have it. > According to the documentation at > https://developer.gnome.org/glib/stable/glib-building.html > GLib can, and is indeed recommended to, be compiled using GLib's > internal version of PCRE (i.e. using the configure script option > --with-pcre=internal). Debian policy is to avoid embedded code copies unless there is a compelling technical reason to use them, and ensure that the system libpcre remains compatible with GLib's usage. This ensures that if there is a security vulnerability in PCRE (which has happened in the past), patching PCRE is sufficient to fix that vulnerability. S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org