Re: PL/perl should fail on configure, not make

On 1/9/13 12:50 PM, Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> On 1/9/13 11:00 AM, Tom Lane wrote:
>>> The libperl-dev package, as constituted, doesn't make any sense: it's
>>> got the symlink which people need, and a very large static (.a) library
>>> that most people don't need. Even worse, you can't tell without close
>>> inspection which of those files is actually used by a package that
>>> requires libperl-dev, and that is something that's important to know.
>
>> The expectation is that if you want to link against libfoo, you install
>> libfoo-dev, and after that you can uninstall it. What's wrong with that?
>
> What's wrong is that it's hard to tell whether the resulting package
> will contain a reference to the shared library (libperl.so.whatever)
> or an embedded copy of the static library. As I tried to explain, this
> is something that a well-run distro will want to be able to control,
> or at least determine automatically from the package's BuildRequires
> list (RPM-ism, not sure what Debian's package management stuff calls the
> equivalent concept). That makes it a bad idea independently of the
> problem of whether two configure tests are needed rather than one.

Yeah, this has nothing to do with how Perl is packaged. The issue of
linking against static vs shared libraries is well understood, but a
separate debate. There are other packaging tools that make sure this
works out. Even if there were no static libraries, libperl-dev might
still exist. The core issue here is that header files and link-time
library files are in different packages that can be installed
separately. Any other library were this choice was made would create
the same issue. The fault is that configure checks only one thing and
assumes two.