#!/usr/bin/perl
# $Id: Build.PL 12 2009-05-09 22:15:56Z whynot $

package main;
use strict;
use warnings;

use version 0.50; our $VERSION = qv q|0.0.5|;

use Module::Build 0.20;

=head1 OVERVIEW

B<File::AptFetch> provides API for APT (Advanced Package Tool, that's the
Debian package management system) methods.
APT methods aren't libraries, they are executables
(placed, by default, in
F<Z<>E<sol>varZ<>E<sol>libZ<>E<sol>aptZ<>E<sol>methods>).
So it's not XS (and can't be), B<F::AF> forks.
However one doesn't need fork for each file or session.
The IPC is B<pipe>
(and can't be anything else
(later, I'll check if socket can be used instead of 2 pipes for each method)).
As you can see there's a limit of number of methods available simultaneously
posed by the maximum number of open filehandles
(APT methods aren't that numerous anyway).

The module is named B<File::AptFetch> because it always fetches.
I think that's possible to develop a method that would bring away files, but,
at present, there's none.
And I doubt there would be any.

Further reading:

=over

=item B<File::AptFetch>

POD of the module.
Covers API and provides examples of intended usage.
B<(bug)> It's underdeveloped yet.

=item B<File::AptFetch::Cookbook>

Provides some useful, I believe, findings on each method behaviour
and an overview, of my understanding, how that stuff works.
Look, APT methods API documentation is quite outdated.
Each method is undocumented completely.
B<(bug)> My knowledge of APT methods is very irregular, so is B<F::AF::C>.

=back

=head1 RUN-TIME REQUIREMENTS

=over

=item B<Perl>

S<B<v. 5.6>> or later.
There're some B<our>es spelled around.

=item B<IO::Pipe>

Any version.
It's distributed with Perl itself, however,
I didn't elaborate to verify since what version.

=back

=head1 BUILD-TIME REQUIREMENTS

=over

=item B<Test::More>

Any version.
Should be distributed with Perl itself too.

=back

=cut

my $builder = Module::Build->new(
  module_name       => q|File::AptFetch|,
  license           => q|lgpl|,
  dist_author       => q|Eric Pozharski <whynot@cpan.org>|,
  dist_version_from => q|lib/File/AptFetch.pm|,
  sign              => 1,
  requires          => {
    perl        => qv(q|5.6|),
    q|IO::Pipe| => '', },
  build_requires    => {
    q|Test::More| => '', },
  PL_files          => {
    ( -f q|README.PL|  ? ( q|README.PL|  => q|README|  ) : ()),
    ( -f q|Changes.PL| ? ( q|Changes.PL| => q|Changes| ) : ()), },
  add_to_cleanup    => [ qw|
    *.tmp *.bak foo.*
    FAF_*_?????? |,
    ( -f q|README.PL|  ? q|README|  : ()),
    ( -f q|Changes.PL| ? q|Changes| : ()), ],);

=head1 BUILD-TIME CONFIGURATION

=over

=cut

#$builder->config_data(lib_method    => q|/usr/lib/apt/methods|);

=item C<lib_method>

That sets location of APT methods.
It's unrequired,
it will be set any time APT configuration is sourced.
L<File::AptFetch/_cache_configuration> and
L<File::AptFetch/_uncache_configuration> have more.

=cut

$builder->config_data(config_source => [ qw| /usr/bin/apt-config dump | ]);

=item C<config_source>

Required.
C<ARRAY> ref that will be B<exec>ed.
L<File::AptFetch/_cache_configuration> has more.

=cut

$builder->config_data(signal        => q|TERM|);

=item C<signal>

Required.
Names a signal that will be sent to method.
L<File::AptFetch/DESTROY> has more.

=back

=cut

$builder->create_build_script();

=head1 TEST-SUITE

Two things should be tested in regard with B<F::AF>:

=over

=item methods and structures

I wouldn't say I'm happy with this part (F<tZ<>E<sol>void.t>).
It's mostly a crash-type testing.
And a problem here is that I'm not completely sure what an input (from methods
side) here could be.

=item APT methods itself

Only local methods are tested.
And I<cdrom> method, among them, is no way touched.
Remote methods are missing from the test-suite.
This problem is easily fixable -- some kind Perlist could upload on CPAN some
modules, in B<Test> namespace, what would provide fake servers of
http:E<sol>E<sol>, ftp:E<sol>E<sol>, rsh:E<sol>E<sol> etc protocols.
Anyone?

=back

And one note.
B<F::AF> is absolutely useles outside APT based world
(I'm not about F<*.deb>, I'm about APT).
Then F<tZ<>E<sol>file.t> and F<tZ<>E<sol>copy.t> skip completely.
Meanwhile F<tZ<>E<sol>void.t> enables some cute workaround, that would provide
all needed C<apt-config(1)> functionality without that executable itself.
(Just in case on that platform there will be Debian some day.)
But we still stay within POSIX world -- no future outside.

=head1 AVAILABILITY

=over

=item pure distribution

# TODO: http://search.cpan.org/dist/File-AptFetch/

=item and debianization stuff too

# TODO: think sharesource

=item subversion (root)

http://svn.sharesource.org/svn/file_apt_fetch

=back

=head1 BUGS

=over

=item please report here

# TODO: http://rt.cpan.org/Public/Dist/Display.html?Name=File-AptFetch

=item please don't report there

# TODO: think sharesource

=back

=head1 COPYRIGHT AND LICENSING

=over

=item *

Copyright 2009 by Eric Pozharski E<lt>whynot@cpan.orgZ<>E<gt>

=item *

AS-IS, NO-WARRANTY, HOPE-TO-BE-USEFUL

=item *

GNU Lesser General Public License v3
E<lt>L<http:E<sol>E<sol>www.gnu.orgZ<>E<sol>licensesZ<>E<sol>lgpl.txt>E<gt>

=back