[bug#70065] [PATCH v2 3/8] gnu: chez-scheme: Reorganize package definitions.

[Philip McGrath <philip@philipmcgrath.com>]

Hi Liliana,

On 4/1/24 11:40, Liliana Marie Prikler wrote:
> Am Montag, dem 01.04.2024 um 02:51 -0400 schrieb Philip McGrath:
>> A future commit will change 'chez-scheme' to inherit from
>> 'chez-scheme-for-racket', so 'chez-scheme-for-racket' will need to be
>> defined before 'chez-scheme'.  In an attempt to produce better diffs,
>> this commit re-orders the definitions while keeping their contents
>> exactly the same.
>>
>> * gnu/packages/chez.scm (chez-scheme): Move below
>> 'chez-scheme-for-racket'.
>> (chez-scheme-bootstrap-bootfiles): Move below
>> 'chez-scheme-for-racket-bootstrap-bootfiles'.
>>
>> Change-Id: Ie088abea2b44329f9d8399fbfb95c51d8912b05e
>> ---
> I don't understand this direction.  Why have chez-scheme inherit from
> chez-scheme-for-racket?  Even if Racket itself pins a particular
> version instead of an upstream release (which, let's face it, would be
> the wiser option here), or requires a special build (again, why?) I
> think keeping the inheritance in the other direction makes ontological
> sense moreso than whatever we're starting here.
> 
> Cheers

We will be using chez-scheme-for-racket to bootstrap chez-scheme. (For 
more rationale, see the comments added to chez.scm in [v2 8/8].) While 
it is possible to have package inheritance go in the opposite direction 
as bootstrapping, my experience before 
daa91a49b2914343afdfcdbea9a22c9d062ba185 was that it was very confusing 
and often triggered unnecessary rebuilds. In this case, it avoids 
potentially rebuilding the entire Racket world when there's a Chez 
Scheme release. (Bootstrapping chez-scheme really does depend on at 
least racket-vm-bc, so we can't avoid rebuilding the Chez Scheme world 
when there's a Racket release.)

Matthew Flatt wrote in <https://racket.discourse.group/t/2739/3>:

> I imagine that Racket's copy of Chez Scheme will be more
> conventionally vendored and aligned with Chez Scheme releases one day,
> but I don't think we're ready to move to that mode in the near future.

I wasn't involved in his efforts together with the other Chez Scheme 
maintainers to merge Racket's changes and to keep development in sync 
going forward, but offhand I can think of both social and technical 
reasons that the approach they've chosen for now makes sense to me.

Thanks,
Philip