[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How to go about `clj`?



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


Reply to: