Main   Changelog   Spec   Patches   Sources   Download   Gear   Bugs and FR  Repocop 

#
#   - Socket::GetAddrInfo -
#   This spec file was automatically generated by cpan2rpm [ver: 2.027]
#   (ALT Linux revision)
#   The following arguments were used:
#       --debug --version 0.10 Socket::GetAddrInfo
#   For more information on cpan2rpm please visit: http://perl.arix.com/
#

%define module Socket-GetAddrInfo
%define m_distro Socket-GetAddrInfo
%define m_name Socket::GetAddrInfo
%define m_author_id unknown
%define _enable_test 1

Name: perl-Socket-GetAddrInfo
Version: 0.10
Release: alt1.1

Summary: %m_name - RFC 2553's getaddrinfo and getnameinfo functions

License: Artistic and GPL
Group: Development/Perl
Url: http://search.cpan.org/dist/Socket-GetAddrInfo/

Packager: Michael Bochkaryov <misha at altlinux.ru>

Source: http://search.cpan.org/CPAN/authors/id/P/PE/PEVANS/%m_distro-%version.tar.gz

# Automatically added by buildreq on Mon Aug 04 2008 (-bi)
BuildRequires: perl-Module-Build perl-Test-Exception perl-version

%description
The RFC 2553 functions getaddrinfo and getnameinfo provide an abstracted way to
convert between a pair of host name/service name and socket addresses, or vice
versa. getaddrinfo converts names into a set of arguments to pass to the
socket() and connect() syscalls, and getnameinfo converts a socket address back
into its host name/service name pair.

These functions provide a useful interface for performing either of these name
resolution operation, without having to deal with IPv4/IPv6 transparency, or
whether the underlying host can support IPv6 at all, or other such issues.
However, not all platforms can support the underlying calls at the C layer,
which means a dilema for authors wishing to write forward-compatible code.
Either to support these functions, and cause the code not to work on older
platforms, or stick to the older "legacy" resolvers such as gethostbyname(),
which means the code becomes more portable.

This module attempts to solve this problem, by detecting at compiletime whether
the underlying OS will support these functions, and only compiling the XS code
if it can. At runtime, when the module is loaded, if the XS implementation is
not available, emulations of the functions using the legacy resolver functions
instead. The emulations support the same interface as the real functions, and
behave as close as is resonably possible to emulate using the legacy resolvers.
See below for details on the limits of this emulation.

%prep
%setup -q -n %m_distro-%version

%build
%perl_vendor_build

%install
%perl_vendor_install

%files
%perl_vendor_archlib/*
%exclude %perl_vendor_man3dir/*
%doc Changes

%changelog
…
Full changelog you can see here