If you are a distro packager, feel free to introduce yourself in a reply to this post.
To get things started, I'm Philip, and I maintain the Guix packages racket, racket-minimal, and zuo, as well as chez-scheme. I'm also a long-time user of Debian and downstream distros: I'm writing this post on Debian with Guix as a "user space" package manager. In the past, I've installed Racket from Debian packages (including the Ubuntu PPA) and from Homebrew.
Philip McGrath via Racket Discourse
notifications@racket.discoursemail.com writes:
Introductions
If you are a distro packager, feel free to introduce yourself in a reply to this post.
I'm the maintainer of the Debian Racket packages (I think some of the
packaging is shared with the PPA these days).
I use racket for university (CS) teaching and (PL / Mathematical Optimization) research.
Hi there! I'm ... not a distro manager.
But I am curious to know whether there are things that I can do as Racket release manager to make your lives easier. Specifically, I think that all of you need to be notified when a new release comes out, but there are also interdependencies; e.g., I think the ubuntu PPA is downstream of the debian package? I'm not quite sure why that is or how that works.
Anyhow, if you can think of a way for me to make y'all's lives easier (I mean aside from doing your laundry or taking your car to the mechanic) let me know.
John Clements via Racket Discourse
notifications@racket.discoursemail.com writes:
Hi there! I'm ... not a distro manager.
But I am curious to know whether there are things that I can do as
Racket release manager to make your lives easier. Specifically, I
think that all of you need to be notified when a new release comes
out, but there are also interdependencies; e.g., I think the ubuntu
PPA is downstream of the debian package? I'm not quite sure why that
is or how that works.
I think it's more of a collaboration at this point. As far as I know the
PPA started with the (slightly eccentric) Debian packaging, but since
then Asumu feeds back the occasional fix to Debian as well. Asumu can
correct me, but I don't think he waits for me to do a Debian upload
before updating the PPA (probably just as well since I am sometimes a
bit slow).
I don't think anything special is needed for "regular" releases, but for
big changes like changing the build system, or changing the default to Chez
Scheme, some kind of pre-release snapshots to test can be helpful.
One place where Debian probably pushes things a bit farther is in
supporting non AMD64/X86 architectures. We currently support 8
architectures fully 1, with riscv64 being in the process of
bootstrapping. I know shamefully little about Racket CI processes, but
anything to test "exotic" architectures would be welcome.
Hello!
I am the main maintainer of Racket in the Gentoo's Scheme (Project:Scheme - Gentoo wiki) project.
Me and tgbugs were also doing stuff with packaging individual racket packages in Gentoo, mostly in the gentoo-racket-overlay (https://gentoo-racket.gitlab.io/) but recently I had not have time for Racket since I was crazy busy taking care of .NET in Gentoo.
In Gentoo we do not have such advanced bootstrap split as in Guix because we also have to take account that normal users will be building from source so up until now I was not interested in splitting Racket bc and cs. But I would be interested if we can have a split between Racket and Zuo in Gentoo
Hey, here's another question. We're currently in the "doc build" part of the release process; everything is done, but the official release is more or less embargoed pending the update of the online docs, which usually takes about 3 days total. Would it be useful to share the URLs of the fully-built and downloadable packages with y'all so you could get ahead of the curve on preparing downstream releases?
FWIW, bundles are currently available at URLs that look like
https://mirror.racket-lang.org/installers/8.11/racket-8.11-aarch64-macosx-cs.dmg
https://mirror.racket-lang.org/installers/8.11/racket-8.11-src.tgz
et al.
Hello package maintainer fellows!
Though 99% of the time I use the Racket binary I built from source,
I am the main maintainer of the Racket package for openSUSE tumbleweed. I've been wanting to add the minimal-racket package to TW, but I haven't had time yet.
I also maintain the Racket flatpak. There are a few issues about using a sandbox Racket. One of them is you can't do raco setup. Also, you can't install a system racket package via raco.
There are a few issues about using a sandbox Racket. One of them is you can't do
raco setup. Also, you can't install asystemracket package via raco.
What is the issue with flatpak? That it wants to write to user or system dir? One can workaround that by setting PLTUSERHOME to location within racket flatpak dir... if that is possible. 
I find it useful to know when releases reach this point. I always follow the "Racket X.YY Release Thread" in Internals, so a note there would work for me.
Guix gets the sources using the Git tags (partially for idiosyncratic reasons), so this isn't directly relevant to me, but I vaguely remember a recommendation at one point to prefer download.racket-lang.org to mirror.racket-lang.org—but I don't remember why. Maybe there was context related to core: use download.racket-lang.org instead of mirror.racket-lang.org · Bogdanp/setup-racket@8050146 · GitHub?
These URLs are probably preferred for essentially the same reason that they don't work until the release is finalized; I believe these links go through "our" website, giving us better control over what they point to. That's a 50% answer at best, my apologies, I'm headed out the door.
Yes, raco setup potentially writes .zo files, but flatpak directories are read-only. Similarly for raco pkg install -i.
Right, but I do not see why you would ever have to use "install" scope...? I think in doc build case racket will reference bot installation and user scope docs.
Hello.
My name is Zygmunt Krynicki. I'm the maintainer of the racket snap package. The package is maintained at zygoon / racket-snap · GitLab
I've just refreshed it to build 8.11.1 and resolved a long-standing bug related to testing the non-prebuilt packages that actually relied on font metrics.
The snap package is curious as packages go, as it runs racket inside a sandbox. There have been some ideas to run racket as a "classic" snap, that runs outside of the sandbox. I've started looking into that. I think that ideally racket would have two snap-store tracks so that people can choose if they want to use the strictly or classically confined snap. The advantage of strict confinement is much better cross-distro support. The disadvantage for open-ended packages such as runtimes and IDEs is integration with other tools is purposefully difficult or impossible.
Apologies for a late start, I've been particularly busy lately. Thank you for the invite @spdegabrielle