Re: Policy for .ph files in packages?
On Mon, Oct 22, 2001 at 09:50:13AM -0500, Preston Smith wrote:
>On Fri, Oct 19, 2001 at 11:17:49PM +0200, Michael Koehne (kraehe@copyleft.de) wrote:
>> - test for existance in postinst, and create them on the fly.
>
> The 'create on the fly in postinst' is the tactic that I chose, but in
> my package, I don't think that this is appropriate, for my package to
> create a ph files in other to make another one work. Of course, I'll ask
> the maintainer of libdevice-serialport-perl to add a creation line in
> his postinst again and see if I get a response this time.
Currently the perl build process only converts a very small number of
the standard (libc6-dev) headers to .ph files. If you need one which
isn't included, please file a bug on perl.
Running h2ph in your postinst has a bundle of problems, not least of
which being that generation of termios.ph requires a dependency on
lib6-dev.
> Might, though, a statement about what to do with .ph files in perl packages
> be a useful thing to have in the Perl policy? There's good information
> about modules and such, but nothing of note for headers.
The use of .ph files generated from C headers by h2ph is deprecated in
favour of compiled modules which export specific constants (Socket.pm
vs. socket.ph for example).
I'm not sure that this requires the weight of policy, but my
recommendation on .ph files is:
* Don't unless you absolutely, positively have to.
* File a bug on perl for headers from libc6-dev which are not included
with perl.
* For other headers, run h2ph in the binary-arch target and install the
results in or under /usr/lib/perl5 .
Regards,
--
Brendan O'Dea bod@compusol.com.au
Compusol Pty. Limited (NSW, Australia) +61 2 9810 3633
Reply to: