File-AptFetch

 view release on metacpan or  search on metacpan

lib/Cookbook.pod  view on Meta::CPAN

Etch'es version of APT method doesn't returns I<$message{md5sum_hash}> and
I<$message{sha256_hash}>.
Since both (Etch'es and Lenny's) versions has I<$message{version}> set to
C<1.0> off C<100 Capabilities> message, you can find out what version of APT
you have only
by experimenting.

=item *

If I<$message{uri}> is unabsolute, then the I<$message{message}> is

    Invalid URI, local URIS must not start with // 

=item *

If I<$message{uri}> has permissions set a way that prohibits read access,
then the method surprisingly succeedes, but hashes are of empty file (puzled).

=item *

I<(v0.1.2)>
EE that laid just here is retracted.
At the time the TS was lazy (units reused samples).
At present I can't verify what was going on in pre-Squeeze.

=item *

I<(v0.1.2)>
(Following route sounds really weird and there isn't RL scenario when it could
possibly happen but that's the way it is.)
As of Wheezy:
(1) file F<foo> isn't readable;
(2) access it;
(3) access all right file F<bar> with leading double-slash URI.
Then get this I<$message{message}>:

    Could not open file %s - open (13 Permission denied) 

But!
It refers F<foo>;
while I<$message{uri}> refers F<bar>.
F<t/file/fail.t> (around C<ftagaab5>) really does it.
No comments.

=item *

If I<$message{message}> points to a directory,
then the behaviour is the same as for the unreadable file.
Even if I<scheme-specific-part> ends with slash.
However, if there are leading double-slash in I<$message{message}>,
then the method complains about invalid URI.

=back

=head2 ftp:

Multiple times sends C<101 Status> messages.
In C<200 URI Start> manifests file size that's coming through
(probably, protocol feature).
Hashes are calculated as bytes are passing in.
I can't say how to pass in credentials.

In C<100 Capabilities> appears I<$message{send_config}> as C<true>.
I<$message{version}> is C<1.0>, who would expect that?

=head2 networking methods

Thorough testing of networking methods pending.
However, I'm pretty sure that default timeout of 2min is enough for now.
Methods itself seem to timeout itself within that frame.
However, I can't say how many times networking methods would reconnect before
giving up.

=head1 SEE ALSO

L<File::AptFetch>,
S<"APT Method Itnerface"> in B<libapt-pkg-doc> package,
B<apt-config(1)>

=head1 AUTHOR

Eric Pozharski, <whynot@cpan.org>

=head1 COPYRIGHT & LICENSE

Copyright 2009, 2010, 2014 by Eric Pozharski

This overview is free in sense: AS-IS, NO-WARANRTY, HOPE-TO-BE-USEFUL.
This overview is released under CC-SA.

=cut

1;



( run in 0.800 second using v1.01-cache-2.11-cpan-39bf76dae61 )