GNU bug report logs - #47153
[PATCH] gnu: chez-scheme: simplify packaging

Previous Next

Full log

View this message in rfc822 format

From: Philip McGrath <philip <at> philipmcgrath.com>
To: Leo Prikler <leo.prikler <at> student.tugraz.at>, 47153 <at> debbugs.gnu.org
Subject: [bug#47153] [PATCH v2] gnu: chez-scheme: Update nanopass to 1.9.2.
Date: Sat, 20 Mar 2021 12:06:14 -0400

Hi,

On 3/16/21 5:09 PM, Leo Prikler wrote:
> Am Dienstag, den 16.03.2021, 16:19 -0400 schrieb Philip McGrath:
>> On 3/16/21 3:37 AM, Leo Prikler wrote:
>>> Am Montag, den 15.03.2021, 18:53 -0400 schrieb Philip McGrath:
>>>> -      (sha256 (base32
>>>> "1synadgaycca39jfx525975ss9y0lkl516sdrc62wrrllamm8n21"))
>>>> +      (sha256
>>>> "16vjsik9rrzbabbhbxbaha51ppi3f9n8rk59pc6zdyffs0vziy4i")
>>> You're inadvertently stripping away base32.
>>
>> I thought I'd read that explicitly calling base32 was redundant and

I think I'd conflated multiple things in my memory. I see that the 
expansion of `package` applies the same special handling of the `sha256` 
field for a literal string as one wrapped with `base32` (recognized with 
`free-identifier=?`), including checking and conversion to a bytevector 
at compile time.

>>>> +            ;; When there's a new tagged release,
>>>> +            ;; go back to using (string-append "v" version)
>>>> +            (commit
>>>> "54051494434a197772bf6ca5b4e6cf6be55f39a5")))
>>> Could we then not cherry-pick this commit as a patch?  Or is there
>>> more
>>> needed?
>>
>> We could, but the upstream history is simply v1.2.2 -> my patch ->
>> Kent
>> Dybvig's merge commit accepting it. I thought doing it this way
>> clarified that it's not a Guix-specific patch that should stay
>> around
>> indefinitely. Is there a reason to prefer cherry-picking it as a
>> patch?
> You'll probably hear differing opinions about that, and that's fine,
> but my personal reason to prefer cherry-picking would be, that it makes
> it very obvious, what changed from the base – that being the patch
> modulo offset changes – and doesn't invite people to go out saying
> "aha, but I found this commit and I like that more, let's take it".  In
> other words, this is very subjective, but I believe we should stick as
> close to releases as is reasonable.

I can understand that perspective. From my point of view, I'm inclined 
to see the release plus one upstream commit (the first commit since 
2017) as closer to the release than a free-floating patch file: with a 
patch, I can see what has changed, but I need to evaluate why it was 
changed, if the change is still necessary, and so forth, rather than 
relying on the upstream maintainers' judgement.


> I don't think we can necessarily trust the boot files in this
> configuration.  "They are bit-for-bit identical" can also mean, that
> the login() hack was successfully applied for all you know.

Yes, the "trusting trust" issues are especially striking if you consider 
that Chez Scheme was non-free software from 1984 to 2016, and the first 
libre release likewise needed the bootfiles of its ancestors.

My point here was just to save space, from the perspective that these 
are build artifacts which can be easily recreated by anyone on a 
GNU/Linux system. But I don't think it's especially important, so I'm 
keeping them.

I hope it might turn out to be possible eventually to bootstrap via 
Racket, maybe even by just picking an older version of the bootstrap 
code before the Racket fork's #!base-rtd gained a vector of ancestors 
rather than a parent and a few such things, but I think there's more to 
be done around Racket packaging before investigating that.

-Philip

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.