Sys::Hostname::hostname() uses ghname() from XS and thus does not fall
back to ph files.
Net::Domain::_hostdomain() indeed tries ph files, but Linux does not
provide getdomainname() syscall. Then it falls back to another
solution.
Net::Domain::_hostname() falls back to POSIX::uname() successfully.
perlfunc/ioctl() recommends sys/ioctl.ph.
perlfunc/syscall() recommends syscall.ph.
perlfaq5 recommends sys/syscall.ph.
The only consumer is xsubpp (ExtUtils::ParseXS) since typemaps are
technically an XS code and ExtUtils::ParseXS only understands them.
But we cannot place ExtUtils/typemap into perl-ExtUtils-ParseXS
because perl-ExtUtils-ParseXS is dual-lived and CPAN code does produce
the typemap file.
The POD files and manual pages are distributed with ExtUtils-ParseXS.
A dual-lived perl-ExtUtils-ParseXS also provides them. Although the
manual pages from perl.spec are in manual section 1 in cotrast to
pages from perl-ExtUtils-ParseXS that are in secrion 3. This looks
like a discrepancy in one of the build scripts.
This is can be invoked with "perl -d", but it requires plenty of
dependencies comparing to perl-interpreter. But because almost nobody
uses it, a subpackage is a better place.
This module name space with methods is implemented in libperl.so. The
module file only supplies a dummy import() method. The module file
exists for a backward compatiblity. Technically we could separate the
module file from perl-libs, but it carry a documentation. The
documentation is similar to one that can be found in perlobj POD, bud
the UNIVERSAL POD is easier to discover.
Petr Písař