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,

-- 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

Reply via email to