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

Christian Ullrich <chris(at)chrullrich(dot)net> writes:
> * Christoph Berg wrote:
>> Re: Tom Lane 2013-01-09 <9802(dot)1357702675(at)sss(dot)pgh(dot)pa(dot)us>
>>> I am unfamiliar with a good reason for doing that. (I can certainly
>>> see segregating the .a static library, or even not shipping it at
>>> all, but what's it save to leave out the .so symlink?)

>> Because the .so symlink is only needed at build time. At runtime, you
>> need the .so.5.14 file. Hence .so.* -> $pkg, .h .a .so -> $pkg-dev.

> That was Tom's point, I believe -- Debian does not do it that way.

> - perl-base has /usr/lib/libperl.so.5.etc
> - perl has the headers and a dependency on perl-base
> - libperl-dev has the symlink /usr/lib/libperl.so > libperl.so.5.etc

> So by installing "perl", you get enough to satisfy configure, but there
> is still no usable -lperl.

Right. [ dons red fedora for packaging purposes... ] The beef that
I've got with this is that there is no sane reason to do it like that.
If you are building C code against a library, you probably need both
some headers and the .so symlink, neither of which will be needed at
runtime; which is why both of those typically go into a foo-dev or
foo-devel subpackage. There are some other situations involving dynamic
loading where you might need the .so symlink at runtime, but in that
case you typically end up deciding that the symlink had better be in the
base package (Debian seems to have chosen this path for Python for
instance).

I'm not terribly familiar with building of Perl extensions, but it seems
possible that there's some use for Perl's C headers in that process,
which might explain why the headers are in "perl" and not a "perl-dev"
subpackage. But since the symlink requires no space to speak of, the
sensible thing to do with it would have been to include it in "perl"
along with the headers.

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.
Under Red Hat packaging rules, the .a library likely wouldn't be shipped
at all; or if there was any demand for it, it would be all by its lonesome
in a package named something like "libperl-static", so that it'd be easy
to tell which packages actually use it. (Think about what happens if a
security update needs to be made in that library ... how do you tell
what has to be rebuilt? And in any case, discouraging use of the static
library will reduce the number of packages to be rebuilt.)

So IMO we're looking at some pretty broken packaging decisions here.
I doubt we'll get Debian to change it, so I don't mind if someone
wants to add a separate configure probe to verify libperl.so is
available --- but as I said upthread, it's not going to be me, because
I'm not in a position to test on the platforms that would be affected.

regards, tom lane