bug#27284: Memory leak in 'guix pull' or 'make' in guix source

[Ricardo Wurmus]

Ludovic Courtès <address@hidden> writes:

>> I was hoping we could avoid this, but whatever: let’s do this :)
>
> Yeah, me too.  The problem we have is that Guix is hardly releasable in
> its current state because on systems with 1GiB of memory you can’t
> upgrade, and I think that’s unacceptable.

Yes, I’m feeling the pain with my i686 netbook.

> So what are the options?  If we get a bug-fix for Guile’s compiler
> today, does it help?  If we graft it then we can deliver it without
> having to wait for a Guile release, which helps a bit?
>
> I think it’s all about time: we could wait (and hack!) some more, and
> solve the root problem.  This is the best long-term course of action,
> but at the same time it delays the Guix release.

The way I see it, having very large modules like (gnu packages python)
is not desirable anyway.  So we won’t get around distributing package
definitions.  If we can get a fix for Guile soon that’s great, but we
should begin moving packages independent of that.

>> For haskell.scm I’d begin by moving the following packages away:
>>
>> - check.scm: ghc-tasty*, ghc-quickcheck*, ghc-test*, ghc-hunit*, hspec*,
>>   ghc-hspec*, …
>>
>> - web.scm: ghc-tagsoup, ghc-cookie, ghc-http*, ghc-wai*, ghc-json,
>>   ghc-warp*, ghc-multipart, ghc-aeson*
>>
>> - crypto.scm: ghc-tf-random, ghc-digest, ghc-cryptonite, ghc-x509*,
>>   ghc-asn1*, ghc-pem, ghc-cryptohash*, ghc-entropy, ghc-crypto-api*,
>>   ghc-puremd5
>>
>> - tls.scm: ghc-tls
>>
>> Maybe that’s enough already.
>>
>> Does that seem like a good idea?
>
> It does.

Okay, I’ll get started with splitting haskell.scm.  I’ll prepare one
patch for each target module.

> Actually, we could do similarly for Perl and Python:
> python-web, python-check, python-crypto, etc.

Okay.  I’ll leave that task for someone else, because I don’t think I
can do more than haskell.scm today.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net