From: Philip McGrath <philip@philipmcgrath.com>
To: Liliana Marie Prikler <liliana.prikler@gmail.com>,
Maxime Devos <maximedevos@telenet.be>,
57683@debbugs.gnu.org
Subject: [bug#57683] [PATCH] gnu: zuo: Use mirrored repository.
Date: Sun, 18 Sep 2022 22:06:49 -0400 [thread overview]
Message-ID: <a9beb36a-797d-f6c2-587c-09fd0c862a51@philipmcgrath.com> (raw)
In-Reply-To: <83f1969678354ee3018449cc6c362a49deb1489e.camel@gmail.com>
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
next prev parent reply other threads:[~2022-09-19 2:08 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-08 17:27 [bug#57683] [PATCH] gnu: zuo: Use mirrored repository Liliana Marie Prikler
2022-09-09 12:42 ` Maxime Devos
2022-09-09 12:55 ` Liliana Marie Prikler
2022-09-19 2:06 ` Philip McGrath [this message]
2022-09-19 13:53 ` Maxime Devos
2022-09-19 18:33 ` Liliana Marie Prikler
2022-09-19 18:40 ` Maxime Devos
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a9beb36a-797d-f6c2-587c-09fd0c862a51@philipmcgrath.com \
--to=philip@philipmcgrath.com \
--cc=57683@debbugs.gnu.org \
--cc=liliana.prikler@gmail.com \
--cc=maximedevos@telenet.be \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.