[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
- Removing compilers that cannot be bootstrapped, Thompson, David, 2016/03/21
- Re: Removing compilers that cannot be bootstrapped, Taylan Ulrich Bayırlı/Kammer, 2016/03/21
- Re: Removing compilers that cannot be bootstrapped, Ludovic Courtès, 2016/03/21
- Re: Removing compilers that cannot be bootstrapped, Jookia, 2016/03/22
- Re: Removing compilers that cannot be bootstrapped, Eric Bavier, 2016/03/22
- Re: Removing compilers that cannot be bootstrapped,
Christopher Allan Webber <=
- Re: Removing compilers that cannot be bootstrapped, Ludovic Courtès, 2016/03/23
- Re: Removing compilers that cannot be bootstrapped, Christopher Allan Webber, 2016/03/23
- Re: Removing compilers that cannot be bootstrapped, Leo Famulari, 2016/03/23
- Re: Removing compilers that cannot be bootstrapped, Ludovic Courtès, 2016/03/25
- Re: Removing compilers that cannot be bootstrapped, Leo Famulari, 2016/03/25
- Re: Removing compilers that cannot be bootstrapped, Chris Marusich, 2016/03/26
- Re: Removing compilers that cannot be bootstrapped, Chris Marusich, 2016/03/26
- Re: Removing compilers that cannot be bootstrapped, Jookia, 2016/03/26
- Re: Removing compilers that cannot be bootstrapped, Alex Vong, 2016/03/26
- Re: Removing compilers that cannot be bootstrapped, Ricardo Wurmus, 2016/03/26