guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Removing compilers that cannot be bootstrapped


From: Christopher Allan Webber
Subject: Re: Removing compilers that cannot be bootstrapped
Date: Tue, 22 Mar 2016 15:29:08 -0700
User-agent: mu4e 0.9.13; emacs 24.5.1

Ludovic Courtès writes:

> "Thompson, David" <address@hidden> skribis:
>
>> Haskell, OCaml, Chicken, and other compilers that we package have a
>> serious issue that many of us are aware of: they cannot be built from
>> source!
>
> (And GCC, but let’s put it aside for now.)
>
>> They rely upon pre-built binaries of the same compiler.  I understand
>> that it's very inconvenient to not have these compilers available to
>> us, and all of the software that is written in their respective
>> languages, but I feel like all of our work is undermined by making
>> exceptions for them.  I would like to remove compilers that don't have
>> a bunch of dependent packages yet such as Chicken until upstream fixes
>> the issue.  But we have tons of Haskell packages and a handful of
>> OCaml packages and it would be heartbreaking to some to remove all of
>> that hard work.
>
> I definitely sympathize with your concerns, and also in the case of
> whole-distro bootstrapping.
>
> However, removing things seems really harsh, and also sidestepping the
> problem (not to mention that once we’d done that, we couldn’t ignore
> GCC’s bootstrapping.)

I agree that removing things seems really harsh... I'd even say too
harsh, in the case of Haskell at least.  I'd really like Guix to be a
good long-term solution for Haskell people.

> address@hidden (Taylan Ulrich "Bayırlı/Kammer") skribis:
>
>> A while back Mark raised the idea of hosting one pre-compiled bootstrap
>> version of each such compiler, and use that to compile further versions.
>>
>> This way the number of blobs is one per such compiler, instead of one
>> for every new version of each such compiler.
>>
>> It seemed like a good medium-term solution to me.  I'm not sure how it
>> would be implemented.
>
> I like the idea.

It sounds good to me too.

Let me give an even shorter-term solution: maybe there is a way to mark
things as risky from a trust perspective when it comes to bootstrapping?
Maybe we could do something like:

  (define-public ghc
    (package
      (name "ghc")
      (version "7.10.2")
      ;; [... bla bla ...]
      (properties '(("bootstrap-untrusted" #t)))))

... or bootstrap-risky, or etc.

This can allow us to move forward with these languages for now while
leaving clear documentation and a way to check trust via the dependency
heierarchy.

Obviously we want there to be no bootstrap-untrusted, and we can work
towards that...

 - Chris



reply via email to

[Prev in Thread] Current Thread [Next in Thread]