One quick question for Alex so it doesn't get lost in my email body: is the versioning scheme of brew-install always going to match that of the current version of Clojure? (i.e. brew-install scripts released alongside Clojure 1.10 will have versions starting with 1.10.x) I'm worried that semversion mismatching may cause confusion. Thoughts on packaging structure to follow: On Mon, Aug 16, 2021 at 04:39:24AM -0300, Leandro Doctors wrote: > As #891141[2] states, the upstream `clj` repo [3] is, in fact, the > repo of the upstream Clojure installer. In fact, if one looks at the > upstream Clojure repo [4], there is no `clojure` wrapper to be found > at all! > > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891141 > [3] https://github.com/clojure/brew-install > [4] https://github.com/clojure/clojure This does not surprise me. The Clojure wrapper script provided in Debian under `usr/bin/clojure (and clojurec) are Debian-specific: https://salsa.debian.org/clojure-team/clojure/-/blob/main/debian/scripts/ > As we can see, it seems there used to be a functionality mismatch > between what was provided upstream and what was provided by Debian. > Moreover, am I wrong, or it seems that Debian introduced the `clojure` > wrapper even before upstream did? Yes, see above. If you look at the commit history, Peter Collingbourne wrote these scripts and included them in the original packaging of Clojure 1.0.0 over 11 years ago. > In any case, if we look at the upstream `clj` code [3], we realize it > simply bundles its own `clojure` wrapper and `rlwrap`. So, there's no > actual `clj`... > > [3] https://github.com/clojure/brew-install There is in fact an actual clj, as well as an upstream clojure entrypoint: https://github.com/clojure/brew-install/blob/1.10.3/src/main/resources/clojure/install/clojure https://github.com/clojure/brew-install/blob/1.10.3/src/main/resources/clojure/install/clj These scripts may need some slight patching to work in a Debian context (see e.g. how the Leiningen bash entry points were patched to point at the correct executable locations for Java). > So... how should we integrate `clj`'s functionalily into Debian? We should manage the new `clojure` command-line script using alternatives. My suggestion would be to: - Package the brew-install repo as source package "clojure-cli" (as the brew-install name is a bit confusing and isn't very explanatory, even if we called it clojure-brew-install... brew is a MacOS-specific package manager) - Ensure that when the upstream clojure script is installed, it doesn't have a name collision with the existing package in Debian, which we need to keep for compatibility. We can potentially deprecate that binary package after at least one release where both are available. - Use alternatives to manage what /usr/bin/clojure points to. - Install /usr/bin/clj as is. - Call this new binary package which contains the new upstream scripts `clj`. That way, both packages are mutually installable and users can configure their alternatives as they like. After it hits testing and has a couple months to soak and get user feedback in Debian, I also think that we should consider uploading clj and its dependencies to stable backports, since we just missed the bullseye release. At this point I don't think we should change what /usr/bin/clojure points to by default. We may want to include a NEWS file in the existing clojure package letting users know that clj is available once published. I'll definitely add it as a "Suggests" package (I'm debating "Recommends" since on most systems a "Recommends" will cause it to be installed by default). If we wanted to deprecate the existing scripts, I'd do it over a few release cycles, e.g. 1. Release upstream clojure/clj in bookworm alongside existing scripts; Debian script is the default per alternatives 2. Increase priority of upstream scripts in next release, indicate Debian scripts are deprecated 3. Remove Debian scripts in following release Note that this is a very long timeframe, since we just released and each release cycle is approximately 2 years. Leandro, let me know if you have any further questions. - e
Attachment:
signature.asc
Description: PGP signature