On 06/12/13 20:48, Philipp Kern wrote:
> So if you version your -dev package, do not install into an unversioned
> place like libtiff5-dev does. :)
It seems to me that the good options are:
* one unversioned -dev package, on the default gcc include path and/or
relying on pkg-config to get the appropriate -I options (good for
upstreams who break API in minor ways somewhat frequently, so "most"
depending projects will just need a binNMU, like libgnome-desktop)
* n parallel-installable versioned -dev packages, *not* on the default
include path, using pkg-config to get the appropriate -I options
(good for upstreams who save up API breaks to do less frequent, more
major changes, like Gtk 2 -> 3)
For the second case, if an upstream installs to
/usr/include/libfoo-4/foo.h I suppose they could expect library users to
#include <libfoo-4/foo.h>... but that guarantees that source changes
will be needed for every API break, even if the subset of the API used
by the application has not actually changed (whereas changing the
pkg-config filename for parallel-installable versions just needs a
one-line change in configure.ac or equivalent).
pkg-config is useful in other situations too (version-checking,
installation into a non-default prefix, etc.) and .pc files are easy to
provide, so I think it should be considered best-practice for upstreams
to provide .pc files for all libraries.
S
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52a316bf.3010...@debian.org
