Log message:
Remove mongodb.
It is imported to pkgsrc as databases/mongodb.

Log message:
Update to 3.0.2

* Remove empty TODO file.

Changelog:

Release Notes for MongoDB 3.0

March 3, 2015

MongoDB 3.0 is now available. Key features include support for the WiredTiger \ 
storage engine, pluggable storage engine API, SCRAM-SHA-1 authentication \ 
mechanism, and improved explain functionality.

MongoDB Ops Manager, which includes Automation, Backup, and Monitoring, is now \ 
also available. See the Ops Manager documentation and the Ops Manager release \ 
notes for more information.
Minor Releases

3.0.2 – April 9, 2015

    Fix inefficient query plans for 2d $nearSphere: SERVER-17469
    Fix problem starting mongod during repair operations with WiredTiger: \ 
SERVER-17652 and SERVER-17729
    Resolved invalid compression stream error with WiredTiger and zlib block \ 
compression: SERVER-17713
    Fix memory use issue for inserts into large indexed arrays: SERVER-17616
    All issues closed in 3.0.2

3.0.1 – March 17, 2015

    Fixed race condition in WiredTiger between inserts and checkpoints that \ 
could result in lost records: SERVER-17506.
    Resolved issue in WiredTiger's capped collections implementation that caused \ 
a server crash: SERVER-17345.
    Fixed issue is initial sync with duplicate _id entries: SERVER-17487.
    Fixed deadlock condition in MMAPv1 between the journal lock and the oplog \ 
collection lock: SERVER-17416.
    All issues closed in 3.0.1

Major Changes
Pluggable Storage Engine API

MongoDB 3.0 introduces a pluggable storage engine API that allows third parties \ 
to develop storage engines for MongoDB.
WiredTiger

MongoDB 3.0 introduces support for the WiredTiger storage engine. With the \ 
support for WiredTiger, MongoDB now supports two storage engines:

    MMAPv1, the storage engine available in previous versions of MongoDB and the \ 
default storage engine for MongoDB 3.0, and
    WiredTiger, available only in the 64-bit versions of MongoDB 3.0.

WiredTiger Usage

WiredTiger is an alternate to the default MMAPv1 storage engine. WiredTiger \ 
supports all MongoDB features, including operations that report on server, \ 
database, and collection statistics. Switching to WiredTiger, however, requires \ 
a change to the on-disk storage format. For instructions on changing the storage \ 
engine to WiredTiger, see the appropriate sections in the Upgrade MongoDB to 3.0 \ 
documentation.

MongoDB 3.0 replica sets and sharded clusters can have members with different \ 
storage engines; however, performance can vary according to workload. For \ 
details, see the appropriate sections in the Upgrade MongoDB to 3.0 \ 
documentation.

The WiredTiger storage engine requires the latest official MongoDB drivers. For \ 
more information, see WiredTiger and Driver Version Compatibility.

See also

Support for touch Command, WiredTiger Storage Engine section in the Storage \ 
documentation
WiredTiger Configuration

To configure the behavior and properties of the WiredTiger storage engine, see \ 
storage.wiredTiger configuration options. You can set WiredTiger options on the \ 
command line.

See also

WiredTiger Storage Engine section in the Storage documentation
WiredTiger Concurrency and Compression

The 3.0 WiredTiger storage engine provides document-level locking and compression.

By default, WiredTiger compresses collection data using the snappy compression \ 
library. WiredTiger uses prefix compression on all indexes by default.

See also

WiredTiger section in the Production Notes
MMAPv1 Improvements
MMAPv1 Concurrency Improvement

In version 3.0, the MMAPv1 storage engine adds support for collection-level locking.
MMAPv1 Configuration Changes

To support multiple storage engines, some configuration settings for MMAPv1 have \ 
changed. See Configuration File Options Changes.
MMAPv1 Record Allocation Behavior Changes

MongoDB 3.0 no longer implements dynamic record allocation and deprecates \ 
paddingFactor. The default allocation strategy for collections in instances that \ 
use MMAPv1 is power of 2 allocation, which has been improved to better handle \ 
large document sizes. In 3.0, the usePowerOf2Sizes flag is ignored, so the power \ 
of 2 strategy is used for all collections that do not have noPadding flag set.

For collections with workloads that consist only of inserts or in-place updates \ 
(such as incrementing counters), you can disable the power of 2 strategy. To \ 
disable the power of 2 strategy for a collection, use the collMod command with \ 
the noPadding flag or the db.createCollection() method with the noPadding \ 
option.

Warning

Do not set noPadding if the workload includes removes or any updates that may \ 
cause documents to grow. For more information, see No Padding Allocation \ 
Strategy.

When low on disk space, MongoDB 3.0 no longer errors on all writes but only when \ 
the required disk allocation fails. As such, MongoDB now allows in-place updates \ 
and removes when low on disk space.

See also

Dynamic Record Allocation
Replica Sets
Increased Number of Replica Set Members

In MongoDB 3.0, replica sets can have up to 50 members. [1] The following \ 
drivers support the larger replica sets:

    C# (.NET) Driver 1.10
    Java Driver 2.13
    Python Driver (PyMongo) 3.0
    Ruby Driver 2.0
    Node.JS Driver 2.0

The C, C++, Perl, and PHP drivers, as well as the earlier versions of the Ruby, \ 
Python, and Node.JS drivers, discover and monitor replica set members serially, \ 
and thus are not suitable for use with large replica sets.
[1]	The maximum number of voting members remains at 7.
Replica Set Step Down Behavior Changes

The process that a primary member of a replica set uses to step down has the \ 
following changes:

    Before stepping down, replSetStepDown will attempt to terminate long running \ 
user operations that would block the primary from stepping down, such as an \ 
index build, a write operation or a map-reduce job.
    To help prevent rollbacks, the replSetStepDown will wait for an electable \ 
secondary to catch up to the state of the primary before stepping down. \ 
Previously, a primary would wait for a secondary to catch up to within 10 \ 
seconds of the primary (i.e. a secondary with a replication lag of 10 seconds or \ 
less) before stepping down.
    replSetStepDown now allows users to specify a secondaryCatchUpPeriodSecs \ 
parameify how long the primary should wait for a secondary to catch up before \ 
stepping down.

Other Replica Set Operational Changes

    Initial sync builds indexes more efficiently for each collection and applies \ 
oplog entries in batches using threads.
    Def.
    Stronger restrictions on Replica Set Configuration. For details, see Replica \ 
Set Configuration Validation.
    For pre-existing collections on secondary members, MongoDB 3.0 no longer \ 
automatically builds missing _id indexes.

See also

Replication t for SSL. Previously, only MongoDB Enterprise distributions came \ 
with SSL support included; for non-Enterprise distributions, you had to build \ 
MongoDB locally with the --ssl flag (i.e. scons --ssl).

32-bit MongoDB builds are available for testing, but are not for production use. \ 
32-bit MongoDB builds do not include the WiredTiger storage engine.

MongoDB builds for Solaris do not support the WiredTiger storage engine.

MongoDB builds are available for Windows Server 2003 and Windows Vista (as \ 
"64-bit Legacy"), but the minimum officially supported Windows version \ 
is Windows Server 2008.

See also

Platform Support, What are the limitations of 32-bit versions of MongoDB?
MongoDB Enterprise Features
Auditing

Auditing in MongoDB Enterprise can filter on any field in the audit message, \ 
including the fields returned in the param document. This enhancement, along \ 
with the auditAuthorizationSuccess parameter, enables auditing to filter on CRUD \ 
operations. However, enabling auditAuthorizationSuccess to audit of all \ 
authorization successes degrades performance more than auditing only the \ 
authorization failures.
Additional Information
Changes Affecting Compatibility

Some changes in 3.0 can affect compatibility and may require user actions. For a \ 
detailed list of compatibility changes, see Compatibility Changes in MongoDB \ 
3.0.
Upgrade Process

See Upgrade MongoDB to 3.0 for full upgrade instructions.
Download

To download MongoDB 3.0, go to the downloads page.

See also

    All Third Party License Notices.
    All JIRA issues resolved in 3.0.

Additional Resources

    Blog Post: Announcing MongoDB 3.0
    Whitepaper: What's New in MongoDB 3.0
    Webinar: What's New in MongoDB 3.0

Log message:
Use bsd.prefs.mk instead of fast version to consistency.

Log message:
Fix distfile checksum

Log message:
Update mongodb to 2.6.9.

2.6.9 - March 24, 2015
- Resolve connection handling related crash with mongos instances
- Add server parameter to configure idle cursor timeout
- Remove duplicated (orphan) documents from aggregation pipelines with
  _id queries in sharded clusters
- Fixed crash in geoNear queries with multiple 2dsphere indexes

2.6.8 - February 25, 2015
- Add listCollections command functionality to 2.6 shell and client
- copydb/clone commands can crash the server if a primary steps down
- Secondary fasserts trying to replicate an index
- Query optimizer should always use equality predicate over unique
  index when possible

Log message:
CVE-2015-1609

Log message:
Update mongodb to 2.6.7.

- Decreased mongos memory footprint when shards have several tags
- Removed check for shard version if the primary server is down
- Fixed: /etc/init.d/mongod startup script failure with dirname message
- Fixed: mongos can cause shards to hit the in-memory sort limit
  by requesting more results than needed

Log message:
Use boost::swap instead of std::swap. Fixes SunOS builds at least.