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=...").
Changelog:
2.134 2007-11-16
(no code changes from previous dev release)
2.133_05 2007-11-11
[BUG FIXES]
added is_available method to MIMEEntity plugin
2.133_04 2007-09-24
[ENHANCEMENTS]
created Email::Abstract::Plugin base class; please use it!
added is_available method to plugins
[BUG FIXES]
is_available in the Mail::Internet adapter should solve header
folding issues (by preventing you from using it when it can't work)
2.133_03 2007-08-??
diagnostics in output to indicate what version of a module we used
2.133_02 2007-07-??
fix test planning
2.133_01 2007-07-??
add test to ensure that "can't handle" exception is thrown ASAP
remove unexplained requirement for perl 5.6
fix Mail::Internet header fetching to unfold headers
fix Mail::Message body setter, which hosed newlines
fix body handling for Mail::Internet
improved consistency of method used to find adapter class
improved tests and test coverage
Pkgsrc changes:
- The package supports installation to DESTDIR.
- This is purely a Perl module.
Changes since version 2.131:
============================
2.132 2007-03-22
packaging improvements
Changes:
2.131 2006-08-22
- pod tests
2.13 2006-07-24
- test for and permit passing Email::Abstract objects to Email::Abstract
class methods
2.12 2006-07-24
- don't use MIME::Entity in test if it's not available
2.11 2006-07-22
- better test planning
2.10 2006-07-21
- add a new method to create wrapper objects
- handle subclasses /properly/ (correct ISA order)
- improved tests and test coverage
- miscellaneous refactoring
- update PEP URL
- update documentation
developer is officially maintaining the package.
The rationale for changing this from "tech-pkg" to "pkgsrc-users" is
that it implies that any user can try to maintain the package (by
submitting patches to the mailing list). Since the folks most likely
to care about the package are the folks that want to use it or are
already using it, this would leverage the energy of users who aren't
developers.
"Email::Abstract" provides module writers with the ability to write
representation-independent mail handling code. For instance, in
the cases of "Mail::Thread" or "Mail::ListDetector", a key part of
the code involves reading the headers from a mail object. Where
previously one would either have to specify the mail class required,
or to build a new object from scratch, "Email::Abstract" can be
used to perform certain simple operations on an object regardless
of its underlying representation.
"Email::Abstract" currently supports "Mail::Internet", "MIME::Entity",
"Mail::Message", "Email::Simple" and "Email::MIME". Other
representations are encouraged to create their own "Email::Abstract::*"
class by copying "Email::Abstract::EmailSimple". All modules
installed under the "Email::Abstract" hierarchy will be automatically
picked up and used.