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 /var/lib/apt/methods). So it's not XS (and can't be), F::AF forks. However one doesn't need fork for each file or session. The IPC is 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 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:

File::AptFetch

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

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. (bug) My knowledge of APT methods is very irregular, so is F::AF::C.

Perl

v.5.8.0 or later. Look, v.5.6.2 is woody. Eight years ago. You must be kidding.

IO::Pipe

Any version. It's distributed with Perl itself. In core since v.5.3.7, predates debian, BTW.

Test::More

Any version. Should be distributed with Perl itself too.

lib_method

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

config_source

Required. ARRAY ref that will be execed. _cache_configuration in File::AptFetch has more.

signal

Required. Names a signal that will be sent to method. DESTROY in File::AptFetch has more.

timeout

(v.0.0.8) Required. I've believed, that could stay hardcoded. I was wrong. _read in File::AptFetch has more.

Two things should be tested in regard with F::AF:

methods and structures

I wouldn't say I'm happy with this part (t/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.

APT methods itself

Only local methods are tested. And 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 Test namespace, what would provide fake servers of http://, ftp://, rsh:// etc protocols. Anyone?

And one note. F::AF is absolutely useles outside APT based world (I'm not about *.deb, I'm about APT). Then t/file.t and t/copy.t skip completely. Meanwhile t/void.t enables some cute workaround, that would provide all needed 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.

pure distribution

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

and debianization stuff too

# TODO

subversion (root)

# TODO

please report here

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

please don't report there

# TODO

• Copyright 2009 by Eric Pozharski <whynot@cpan.org>
• AS-IS, NO-WARRANTY, HOPE-TO-BE-USEFUL
• GNU Lesser General Public License v3 http://www.gnu.org/licenses/lgpl.txt