GNU bug report logs - #57683
[PATCH] gnu: zuo: Use mirrored repository.

Previous Next

Full log

Message #14 received at 57683 <at> debbugs.gnu.org (full text, mbox):

From: Philip McGrath <philip <at> philipmcgrath.com>
To: Liliana Marie Prikler <liliana.prikler <at> gmail.com>,
 Maxime Devos <maximedevos <at> telenet.be>, 57683 <at> debbugs.gnu.org
Subject: Re: [bug#57683] [PATCH] gnu: zuo: Use mirrored repository.
Date: Sun, 18 Sep 2022 22:06:49 -0400

Hi,

I only happened to see this patch just now when looking up a reference 
for something else. The guix-patches and bug-guix are too high-volume 
for me to follow closely.

On 9/9/22 08:55, Liliana Marie Prikler wrote:
> Am Freitag, dem 09.09.2022 um 14:42 +0200 schrieb Maxime Devos:
>> On 08-09-2022 19:27, Liliana Marie Prikler wrote:
>>> This makes it so that zuo follows our packaging guidelines on
>>> version numbers
>>> and gives meaning to the home-page.
>>>
>>> * gnu/packages/racket.scm (zuo)[version]: Use git-version.
>>> [source]: Use “https://github.com/racket/zuo”  as URL.
>>> Adapt patches accordingly.
>>
>> Why the switch from upstream to a mirror?
>>
>> For the home-page:
>> https://github.com/racket/racket/tree/master/racket/src/zuo appears
>> to be upstream (and also meaningful).
> The mirror is noted as home-page (you have to ask Philip as to why),

I hadn't heard concern about the home-page until now. If 
<https://github.com/racket/zuo> is a problem I'd prefer 
<https://github.com/racket/racket/tree/master/racket/src/zuo>, as Maxime 
suggested, or even <https://docs.racket-lang.org/zuo/>, rather than 
switching to a mirror.

> but more importantly, it makes versioning easier.

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.  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.

If you don't like:

-      (version (string-append %zuo-version
-                              "-racket"
-                              %racket-version
-                              (if revision "-guix" "")
-                              (or revision "")))

I'd be fine with `(git-version %zuo-version revision %racket-commit)`.

> Also, it lets us
> update zuo independently of racket

I think that would be counterproductive, as I tried at length to explain 
in <https://issues.guix.gnu.org/57050#46>. Racket has a strong 
commitment to compatibility for public APIs, but things that are 
developed in the main repository are there because they rely on 
especially close integration with the core runtime system: there is no 
attempt to make arbitrary versions work together. In fact, package 
catalogs, snapshots, releases, development builds, and the package 
system all have mechanisms to keep the versions in sync. I don't know of 
any concrete issues with the C-based Zuo implementation specifically, 
but I can say no one is going to put any effort into making Racket's 
build scripts work with any version of Zuo other than the one they are 
developed with.

> (see the backport that we no longer
> have to apply)

If you want to avoid "racket-backport-8.6-zuo.patch", I would even 
prefer giving 'zuo' an origin that inherits from '%racket-origin' but 
uses commit cf82706c4b298f654a04c4bc8d98dff39b62a2ac rather than 
switching to the mirror repository.

I think it's even better to have a consistent source tree for the main 
Racket repository, but at least keeping the repository in the right 
shape would keep --with-git-url/--with-commit working. The mirror 
repository is not useful for development.

> and hopefully allows us to unbundle zuo from racket
> later.
> 

Either I don't understand what you have in mind or I just disagree that 
it's desirable.

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?

-Philip

Previous Next

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