pkgsrc - [no description]

Age	Commit message (Collapse)	Author	Files	Lines
2020-08-31	*: bump PKGREVISION for perl-5.32.	wiz	1	-2/+2

2019-08-11	Bump PKGREVISIONs for perl 5.30.0	wiz	1	-2/+2

2018-08-22	Recursive bump for perl5-5.28.0	wiz	1	-2/+2

2017-06-05	Recursive revbump from lang/perl5 5.26.0	ryoon	1	-2/+2

2016-06-08	Bump PKGREVISION for perl-5.24.	wiz	1	-2/+2

2015-07-12	Comment out dependencies of the style	wiz	1	-2/+2
	{perl>=5.16.6,p5-ExtUtils-ParseXS>=3.15}:../../devel/p5-ExtUtils-ParseXS since pkgsrc enforces the newest perl version anyway, so they should always pick perl, but sometimes (pkg_add) don't due to the design of the {,} syntax. No effective change for the above reason. Ok joerg
2015-06-12	Recursive PKGREVISION bump for all packages mentioning 'perl',	wiz	1	-2/+2
	having a PKGNAME of p5-*, or depending such a package, for perl-5.22.0.
2014-05-29	Bump for perl-5.20.0.	wiz	1	-2/+2
	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.
2013-12-09	Fix/Update DEPENDS paterns for perl CORE modules, with some trivial fixes.	obache	1	-3/+3
	Bump PKGREVISION for runtime dependency pattern changed packages.
2013-05-31	Bump all packages for perl-5.18, that	wiz	1	-2/+2
	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.
2012-10-08	Drop PKG_DESTDIR_SUPPORT setting, "user-destdir" is default these days.	asau	1	-3/+1

2012-10-03	Bump all packages that use perl, or depend on a p5-* package, or	wiz	1	-2/+2
	are called p5-*. I hope that's all of them.
2011-08-14	Revision bump after updating perl5 to 5.14.1.	obache	1	-2/+2

2010-08-21	Bump the PKGREVISION for all packages which depend directly on perl,	seb	1	-2/+2
	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!
2008-10-19	Bump the PKGREVISION for all packages which depend directly on perl,	he	1	-1/+2
	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=...").
2008-06-20	Add DESTDIR support.	joerg	1	-1/+3

2007-10-11	Add p5-IMAP-Client-0.13 (and its small dependency, p5-URI-imap).	tv	1	-0/+21
	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.