Package: opam Version: 2.0.0-1 Severity: normal Dear Maintainer,
I ran "opam init" on my little machine that has only 2GB of RAM and had to kill it after gringo had gobbled all the available memory. I just tried on a bigger computer to see that it peaks at 3 or 4GB, making it unusable on small machines. I wondered why, and how to mitigate this: maybe gringo is not the best default choice for the chain of dependencies (opam -> aspcud -> gringo) in opam's case? Is it a bug in opam 2 (I had not noticed a problem with the previous version), giving a terrible problem to solve to aspcud? Best regards, Samuel -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.17.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages opam depends on: ii aspcud 1:1.9.4-1 ii build-essential 12.5 ii curl 7.61.0-1 ii libbz2-1.0 1.0.6-9 ii libc6 2.27-5 ii opam-docs 2.0.0-1 ii opam-installer 2.0.0-1 ii packup 0.6-3 ii unzip 6.0-21 ii wget 1.19.5-1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages opam recommends: ii darcs 2.14.0-1 ii git 1:2.19.0~rc1-1 ii m4 1.4.18-1 ii mercurial 4.7-1 ii ocaml 4.05.0-10+b1 ii rsync 3.1.2-2.2 opam suggests no packages. -- no debconf information