[bug#57683] [PATCH] gnu: zuo: Use mirrored repository.

[Liliana Marie Prikler <liliana.prikler@gmail.com>]

Am Montag, dem 19.09.2022 um 15:53 +0200 schrieb Maxime Devos:
> On 19-09-2022 04:06, Philip McGrath wrote:
> > When I hear the word "unbundle", I think of configuring Racket and
> > Chez Scheme to use our shared Zlib and removing their vendored
> > copies. I don't see how the concept applies usefully to the
> > scenario of multiple pieces of software, some of which are useful
> > independently, being developed upstream in the same source tree.
> > Like, what would it mean to "unbundle" gfortran from gcc?
> 
> In case of gcc, I think updating the components separately doesn't
> make much sense (from what I hear, it's the same situation for Racket
> and Zuo, where 'Zuo' is just a component of Racket, not something 
> independent that's 'merely' a dependency of Racket).
I'd like to point out that the purpose of Zuo is basically having a
schemey make.  We don't bundle make with GCC, do we?

Am Sonntag, dem 18.09.2022 um 22:06 -0400 schrieb Philip McGrath:
> To me, it seems to make versioning significantly harder. A version 
> number like 1.0-1.dcde608b doesn't communicate probably the most 
> important fact about the Zuo version, which is how it relates to the
> Racket version.
That's exactly the point, though; there's no reason it has to.  As long
as Racket builds with Zuo, I don't see a reason to communicate this
information.

> There is no 'v8.6' tag in the mirror repository (which may just have
> been an oversight), and commits there don't give the original commit
> id (I will suggest that upstream), so you have to manually match up
> commit messages in the logs.
Separate packages can have separate versioning schemes.  As far as I'm
aware, Zuo is starting a fresh counting round, so it doesn't make too
much sense to link its versioning to Racket (particularly if as you
point out it has uses besides bootstrapping Racket).

As for matching up commits when updating, I'm pretty sure this part of
the process could be automated if you feel particularly lazy, but even
if not, a properly configured git forge ought to give you the commit
hash by searching part of its message (on the zuo end) and also allow
you to see the last commit that modified a subtree (on the racket end).

Cheers