Upstream changes:
3.008 2014-12-27 18:36:19-05:00 America/New_York
- make results of get_body be the same on Email::{Simple,MIME}
- ...but this method is a mess, so maybe avoid using Abstract for body
work
3.007 2013-12-31 10:39:14 America/New_York
fix skip count when MIME::Entity is not present
Do it for all packages that
* mention perl, or
* have a directory name starting with p5-*, or
* depend on a package starting with p5-
like last time, for 5.18, where this didn't lead to complaints.
Let me know if you have any this time.
a) refer 'perl' in their Makefile, or
b) have a directory name of p5-*, or
c) have any dependency on any p5-* package
Like last time, where this caused no complaints.
Change from previous:
3.004 2011-02-18
If present, MIME::Entity must be v5.501; v5.500 had a regression (or
a bug fix, depending how you look at it) that broke header-reading.
While technically older versions that are not 5.500 would work, it is
much simpler to just require the newest version, rather than to
support a version range with a hole in it.
pkgsrc changes:
- tidy
- add license definition
- adjust dependencies
Upstream changes:
3.002 2010-06-11
avoid a warning in MailInternet with zero headers found
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=...").
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.