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.
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=...").
- took maintainership
Changelog:
2.004 2008-06-25
publicize default_header_class method
remove the long-deprecated Headers.pm
2.003 2007-07-19
improve tests, for 5.5 compat
remove conditional circular prereq on Email::MIME, replace it with a
warning and delay
2.002 2007-07-14
change initialization order to unbreak Email::MIME
do not return ->body from ->body_set to simplify subclass behavior
2.001 2007-07-13
fix t/perl-minver.t to properly skip if T::MV not installed
retroactively set 2.000 release date!
2.000 2007-07-13
huge improvement to speed of bodyless message parsing
pointed out by Dan Dascalescu; thanks!
more documentation of header class
new Header crlf defaults to real CRLF
fix tests to avoid requiring 5.6
Pkgsrc changes:
- DESTDIR support
- Added CONFLICTS line to follow the comments in Makefile.PL (see 1.998 below)
Changes since version 1.995:
============================
1.999 2007-03-20
fix bug 25496: deletion of headers affected the wrong range,
sometimes deleting too many headers -- thanks, Nicholas Oxhoej!
fix bug 24922: errant space in last header of CRLF-delim email
thanks, Barry Downes and Alex Vandiver
1.998 2007-02-07
MAJOR REFACTORING OF GUTS
If you run Email::MIME, you MUST be running Email::MIME 1.857 or
better.
require Email::MIME 1.857 in Makefile.PL only if an older
version is already installed
boldly moving forward with refactored headers and
Email::Simple:::Header
greatly reduce memory footprint
add crlf method to allow other modules to avoid ->{mycrlf}
fix broken header-junk test
1.996 2006-11-27
- do not wrap Content-Type field; it can cause Outlook to go nuts
while this is a special case, it does not make E::S incorrect, as folding
long headers is allowed (for aesthetics) and not mandated
Changes:
1.995 2006-10-19
- tentative refactoring of headers
1.992 2006-10-05
- fix a number of bugs when setting multiple headers, which would often
refuse to set more values than were currently present
- added a test for prepending (rather than appending) headers; while E::S
does not yet support this, the header behavior will be easier to replace in
future versions, and this is a forward-looking test
1.990 2006-09-05
- ->header('foo') returns false if there is no foo header (formerly '')
- croak if an undef value is passed to new()
1.980 2006-08-17
- fix _fold() to add a missing line ending [RT #20764] (Brian Cassidy)
1.970 2006-08-17
- bring ->headers method into Email::Simple
- ->header_names and ->header_pairs
1.96 2006-07-28
- output headers in predictable order
- give tests more meaningful names
- improved test coverage
1.95 2006-07-21
- update PEP url
- reorganize dist
1.94 2006-07-03
- Fix folding of long headers with \r as line ending (thanks Adam Worrall)
- add tests for message with no body
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::Simple" is the first deliverable of the "Perl Email Project", a
reaction against the complexity and increasing bugginess of the
"Mail::*" modules. In contrast, "Email::*" modules are meant to be
simple to use and to maintain, pared to the bone, fast, minimal in their
external dependencies, and correct.
