to trigger/signal a rebuild for the transition 5.10.1 -> 5.12.1.
The list of packages is computed by finding all packages which end
up having either of PERL5_USE_PACKLIST, BUILDLINK_API_DEPENDS.perl,
or PERL5_PACKLIST defined in their make setup (tested via
"make show-vars VARNAMES=..."), minus the packages updated after
the perl package update.
sno@ was right after all, obache@ kindly asked and he@ led the
way. Thanks!
to trigger/signal a rebuild for the transition 5.8.8 -> 5.10.0.
The list of packages is computed by finding all packages which end
up having either of PERL5_USE_PACKLIST, BUILDLINK_API_DEPENDS.perl,
or PERL5_PACKLIST defined in their make setup (tested via
"make show-vars VARNAMES=...").
From DESCR:
This module was created as a low-level inteface to any IMAP server. It
was built to be a 'clear box' solution to working with an IMAP environ-
ment. The idea is that anything an IMAP client should be able to do,
and any information available via the IMAP specs, should be available
to a client interface and user. This way, the full strength of the
IMAP protocol and data can be utilized, ideally in the most network-
efficient mannger possible, rather than being contrained only to a sub-
set of commands or data-limited responses. If the server says it, the
client should be able to see it.
This module also takes steps to be able to handle anticipated situa-
tions for the user rather than forcing a per-implementation behavior
for such expected events, such as referrals. IMAP::Client will fully
support referrals, and will transparently handle them for whatever com-
mand is issued to them (so long as the referral s for anonymous or the
same user with the same password - a new user or different password
would require a new username/password to be obtained. As of 0.01, this
is not supported, however the framework is down.
This module also tries to follow the various RFCs for IMAPrev1 communi-
cations very closely, enforcing client-side responsabilities where
appropriate.
