| Git Clone URL: | https://aur.archlinux.org/mongodb.git (read-only, click to copy) |
|---|---|
| Package Base: | mongodb |
| Description: | A high-performance, open source, schema-free document-oriented database |
| Upstream URL: | https://www.mongodb.com/ |
| Keywords: | database document-oriented nosql |
| Licenses: | SSPL-1.0 |
| Provides: | mongodb |
| Submitter: | felixonmars |
| Maintainer: | pricechrispy |
| Last Packager: | pricechrispy |
| Votes: | 37 |
| Popularity: | 0.147453 |
| First Submitted: | 2019-01-18 22:08 (UTC) |
| Last Updated: | 2025-10-03 16:57 (UTC) |
@azcn2503, what version of the dependency python-cheetah3 do you have installed? Likely, you need to upgrade that AUR package to 3.2.4-2. Please let me know either way. If this doesn't work, are you using makepkg, devtools, or an AUR helper?
EDIT: If you already have python-cheetah3 3.2.4-2 installed, try rebuilding it and reinstalling it. Possibly its dependencies changed and require a rebuild.
Attempting to upgrade from 4.2.1-1 to 4.2.2-1 and receiving the following error:
Creating 'build/opt/mongo/config.h'
/usr/bin/python src/mongo/base/generate_error_codes.py src/mongo/base/error_codes.err src/mongo/base/error_codes.tpl.h=build/opt/mongo/base/error_codes.h src/mongo/base/error_codes.tpl.cpp=build/opt/mongo/base/error_codes.cpp
Traceback (most recent call last):
File "src/mongo/base/generate_error_codes.py", line 45, in <module>
from Cheetah.Template import Template
ModuleNotFoundError: No module named 'Cheetah'
@Hi-Angel - sorry for not having responded earlier. I can't reproduce your problem. mongodb.tmpfiles is used to create the /var/{lib,log}/mognodb directories, and appears to be working fine for me. I even tried removing the package, removing the directories, and installing the package without non-existent directory errors.
@jiri.one - mongodb used to be in the official repos, but was dropped because upstream made a license change that was unclear (at best) whether it could be redistributed prepackaged, so it was dropped to the AUR. So, sorry, but it doesn't look like it's a candidate for going back to an official package.
Hi,have someone repo for mongodb? I know mongodb-bin, but better will be real Arch build.
Please, add the following directories to the PKGBUILD:
/var/lib/mongodb
/var/log/mongodb
These two are written in the default mongodb.conf that is shipped, and without them mongod fails to start with "non-existent directory" errors.
archer666 - It just compiled fine for me, so I do think this was probably an out of memory issue. You could try the following things:
* Decreasing the number of cores you're allowing it to use while building which will decrease the amount of memory usage.
* Create additional swap space, even if you remove it after building. (If you can use a swap file, that will let you avoid partitioning.)
* Remove check() from the PKGBUILD. I generally think it's a very good idea to run this, but on current packages, it just passed tests for me, and I see that's the phase you ran out of memory in.
4.2.1 - no good
scons: building terminated because of errors. build/opt/mongo/db/s/collection_range_deleter_test.o failed: Error 1 ==> ERROR: A failure occurred in check(). Aborting... ==> ERROR: Makepkg was unable to build mongodb.
g++: fatal error: Killed signal terminated program cc1plus
Looks like out of memory - 16GB machine, I terminated almost everything, 10GB RAM free at least.
lsr, I opened a bugreport upstream at https://jira.mongodb.org/browse/SERVER-44038
I'm baffled at what I found. Removing the line that forces ggdb that you brought up reduces my makepkg (so, tests are still ran) build size from 259GB to 2.3GB, and reduces the build from 70 minutes to 44 minutes. For users with platter drives, I think it will have an even more dramatic reduction in build times.
I tried several ways to get -O2 optimization, with no success.
I'm wondering if there's an intentional reason why they're doing this on posix, so am being cautious and waiting to hear back from upstream before I release a new version. I mean, I'd have to assume they would have noticed at some point in the past performance significantly dropped and have found they were forcing debug builds and no optimization, right?..... The stripped binary size doesn't change, but maybe there's some quirk here we're not aware of.
lsr, awesome catch. I'm baffled by this, and can't wait to see how much faster mongodb performs. I know version 4.0.6 (when mongodb was dropped from community) had a similar build time and size requirement. It will be interesting to know how/when/why this came about. I'll admit I never looked through the SConstruct file other than having to do with system library options, and just went off upstream's compilation instructions which of course don't mention this. I'll be running compilation size and time benchmarks as is, without the forcing of -ggdb you pointed out, and also without -ggdb and the release option for optimization. I'll be posting back here, and likely be filing a bugreport upstream. I'm hoping fixing this and using optimizations won't drastically increase compilation times, but my guess is it will, we'll see...
Pinned Comments
pricechrispy commented on 2025-10-03 16:59 (UTC)
Before upgrading to 8.2, you must set the feature compatibility version to 8.0. See documentation: https://www.mongodb.com/docs/manual/release-notes/8.2-upgrade-standalone/#feature-compatibility-version
Note that building takes about 84gb of memory as of 8.2.1.