[bug#55248] [PATCH 1/7] gnu: racket: Update to 8.5.

[Liliana Marie Prikler <liliana.prikler@ist.tugraz.at>]

Hi,

Am Donnerstag, dem 05.05.2022 um 17:49 -0400 schrieb Philip McGrath:
> Hi,
> 
> On 5/4/22 02:53, Liliana Marie Prikler wrote:
> > Am Dienstag, dem 03.05.2022 um 14:33 -0400 schrieb Philip McGrath:
> > > * gnu/packages/patches/racket-gui-tethered-launcher-
> > > backport.patch,
> > > gnu/packages/patches/racket-enable-scheme-backport.patch: Delete
> > > files.
> > > * gnu/local.mk (dist_patch_DATA): Remove them.
> > LGTM.
> > > * gnu/packages/chez.scm (chez-scheme-for-racket): Update to
> > > 9.5.7.6.
> > This...
> > > * gnu/packages/racket.scm (%racket-version): Update to 8.4.900.
> > ... and this might be done in different commits.
> 
> Since 'chez-scheme-for-racket' uses the same origin as the Racket VM 
> packages, I think the versions have to be updated at the same time, 
> short of having a commit where one of them is incorrect or doing 
> something needlessly complicated.
Fair enough, go ahead.

> 
> [...]
> > > [patches]: Remove obsolete patches.
> > LGTM.
> > 
> > > (racket-vm-common-configure-flags): Remove incorrect comment.
> > No.  Unless you address the issue at hand (which I don't want to be
> > a blocker for this series, mind you), it persists.  If you don't
> > like how the comment is written currently, you might suggest an
> > alternative formulation, but people deserve to know that the
> > origtree layout is a hack.
> 
> I understand that this is your opinion. I disagree. I don't want to
> make a big deal out of it, but I'm uncomfortable with the fact that
> `git blame` currently attributes to me a statement of opinion which I
> did not write and do not believe.
Well, I'm uncomfortable with the fact that git assigns blame to people.
The wording of the command name is (as many things in git) poorly
chosen, but that's somewhat besides the point.  I'm leaving open the
option of writing a comment that you're more comfortable with, but I'm
not leaving the option of silently removing it.

> I could write a lot of prose arguing in favor of --enable-origtree as
> a matter of opinion, but I'd rather spend my time trying to write a 
> racket-build-system, which I expect will make its usefulness more 
> obvious. 
You can argue in favour of it, but that doesn't change the fact that
this layout breaks assumptions that are held elsewhere.  "Dump
everything into a single directory" has never been a good deployment
strategy, and those who use it tend to regret their decision later.

> For now, I'll limit myself to noting that, while Racket 
> supports --enable-unix-style for those who insist on it (a group
> which formerly included me!), if you run the Racket installer script
> [1] with default options, it will install the files that 'racket-vm-
> cs' and similar place in "/opt/racket-vm/" in "/usr/racket".
> Optionally, the installer will then create symlinks is "/usr/bin"
> etc. pointing to a subset of the files that Guix's 'racket-minimal'
> installs into'#$output'.
This paragraph does not make as much sense to another person as you
believe it does.  If I'm counting correctly, we're talking about three
different configurations right now.  --enable-origtree, --enable-unix-
style, and a default that uses neither of the two.  I don't think we 
can easily draw inferences from either to the others.

> To the extent that there is an assertion of fact embedded in:
> 
> > > -      ;; XXX: origtree layout is required by some other packages
> > > down the
> > > -      ;; bootstrap chain.  Remove these flags as soon as we can
> > > do without them.
> 
> it is not true. The packages which operate on a Racket installation
> with this layout (e.g. 'distro-build' and 'raco-cross') are not part
> of "the bootstrap chain", and the packages which are part of the
> bootstrap chain do not require --enable-origtree, except to the
> extent that e.g. it is a convenient way of telling apart multiple
> executables named "racket".
From my POV "the bootstrap chain" consists of everything from the first
VM to the final racket package.  In that sense, I am sure you
communicated elsewhere that it is very important to get layers going,
and I'm also fairly certain that we can't currently build the VM chain
without origtree either -- at least it would require nontrivial
modification of said packages.

Again, if you have a formulation that is more factual, but doesn't span
several pages like other comments in racket.scm do, you are free to
replace it.  However, for the sake of a racket-build-system even, I
suggest that it would be better if racket's own layout was meaningful.
In other words, why can't racket be more like guile and support
RACKET_LOAD_PATH and RACKET_LOAD_COMPILED_PATH?

> > 
Cheers