rename :DEBIAN-SBCL -> :SBCL & use a property to install sbcl

Unconditionally calling apt was actually the only Debian-specific thing about
the connection type.

Signed-off-by: Sean Whitton <spwhitton@spwhitton.name>

9 files changed, 48 insertions, 38 deletions

diff --git a/README.rst b/README.rst
index 1134c79..264b7ee 100644
--- a/README.rst
+++ b/README.rst
@@ -22,7 +22,7 @@ Debian machine as an unprivileged user, using sudo to become root, and then
 starting up a Lisp image to execute your deployment code, you would just
 evaluate::
 
-  (deploy (:ssh (:sudo :as "spwhitton@athena.example.com") :debian-sbcl) athena.example.com)
+  (deploy (:ssh (:sudo :as "spwhitton@athena.example.com") :sbcl) athena.example.com)
 
 Declarative configuration management systems like Consfigurator and Propellor_
 share a number of goals with projects like the `GNU Guix System`_ and
diff --git a/consfigurator.asd b/consfigurator.asd
index d8cd9c5..9a36fa6 100644
--- a/consfigurator.asd
+++ b/consfigurator.asd
@@ -24,13 +24,6 @@
 	       (:file "src/deployment")
 	       (:file "src/connection/local")
 	       (:file "src/data")
-	       (:file "src/connection/shell-wrap")
-	       (:file "src/connection/ssh")
-	       (:file "src/connection/sudo")
-	       (:file "src/connection/debian-sbcl")
-	       (:file "src/connection/chroot")
-	       (:file "src/connection/chroot/fork")
-	       (:file "src/connection/chroot/shell")
 	       (:file "src/property/cmd")
 	       (:file "src/property/file")
 	       (:file "src/property/os")
@@ -38,5 +31,12 @@
 	       (:file "src/property/apt")
 	       (:file "src/property/chroot")
 	       (:file "src/property/user")
+	       (:file "src/connection/shell-wrap")
+	       (:file "src/connection/ssh")
+	       (:file "src/connection/sudo")
+	       (:file "src/connection/sbcl")
+	       (:file "src/connection/chroot")
+	       (:file "src/connection/chroot/fork")
+	       (:file "src/connection/chroot/shell")
 	       (:file "src/data/asdf")
 	       (:file "src/data/pgp")))
diff --git a/doc/connections.rst b/doc/connections.rst
index e14aa82..7e81826 100644
--- a/doc/connections.rst
+++ b/doc/connections.rst
@@ -58,11 +58,11 @@ use the ``chroot(2)`` system call anyway).  More generally, you should avoid
 using this connection type within a Lisp image which might try to execute
 other deployments in parallel.  Typical usage would be something like::
 
-  (deploy (:sudo :debian-sbcl (:chroot.fork :into "...")) ...)
+  (deploy (:sudo :sbcl (:chroot.fork :into "...")) ...)
 
 In some situations you might want to have a connection chain which effectively
-uses a connection type like ``:DEBIAN-SBCL`` twice in a row, so that the first
-Lisp image can execute deployments in parallel while the second forks into the
+uses a connection type like ``:SBCL`` twice in a row, so that the first Lisp
+image can execute deployments in parallel while the second forks into the
 chroot (typically by having a ``DEPLOYS`` property with connection type
-``:DEBIAN-SBCL`` as one of the properties applied by a deployment whose
-connection chain itself ends with ``:DEBIAN-SBCL``).
+``:SBCL`` as one of the properties applied by a deployment whose connection
+chain itself ends with ``:SBCL``).
diff --git a/doc/ideas.rst b/doc/ideas.rst
index 86886f7..d84e8e8 100644
--- a/doc/ideas.rst
+++ b/doc/ideas.rst
@@ -9,14 +9,13 @@ Properties
 Connections
 -----------
 
-- :DEBIAN-SBCL could (fork and) SAVE-LISP-AND-DIE.  That way, we have
-  something that a cronjob can call to re-run the deployment to ensure that
-  all properties remain applied.  Need to think about how the property which
-  sets up the cronjob will be specified in consfigs -- does it make sense to
-  allow passing in arbitrary deployments, or do we only allow re-running
-  exactly the same thing?  If the former, the saved image will need to take
-  some sort of command line input telling it what arguments to pass to
-  DEPLOY*.
+- :SBCL could (fork and) SAVE-LISP-AND-DIE.  That way, we have something that
+  a cronjob can call to re-run the deployment to ensure that all properties
+  remain applied.  Need to think about how the property which sets up the
+  cronjob will be specified in consfigs -- does it make sense to allow passing
+  in arbitrary deployments, or do we only allow re-running exactly the same
+  thing?  If the former, the saved image will need to take some sort of
+  command line input telling it what arguments to pass to DEPLOY*.
 
 - Basic infrastructure for connections which work with just input and output
   streams connected to an interactive POSIX sh somewhere, like TRAMP, and
diff --git a/doc/introduction.rst b/doc/introduction.rst
index 3cc12a7..f724401 100644
--- a/doc/introduction.rst
+++ b/doc/introduction.rst
@@ -46,7 +46,7 @@ Try it out / quick start
 	(defparameter my-substitution "substititions")
 
         (defhost athena.example.com
-	    (:deploy (:ssh (:sudo :as "spwhitton@athena.example.com") :debian-sbcl))
+	    (:deploy (:ssh (:sudo :as "spwhitton@athena.example.com") :sbcl))
           "Web and file server."
 	  (os:debian-stable "buster" :amd64)
 
diff --git a/src/connection/debian-sbcl.lisp b/src/connection/sbcl.lisp
index c5daa5e..4ed465c 100644
--- a/src/connection/debian-sbcl.lisp
+++ b/src/connection/sbcl.lisp
@@ -15,11 +15,21 @@
 ;;; You should have received a copy of the GNU General Public License
 ;;; along with this program.  If not, see <http://www.gnu.org/licenses/>.
 
-(in-package :consfigurator.connection.debian-sbcl)
+(in-package :consfigurator.connection.sbcl)
 (named-readtables:in-readtable :consfigurator)
 
-(defmethod establish-connection ((type (eql :debian-sbcl)) remaining &key)
-  (mrun "which sbcl >/dev/null 2>&1 || apt-get -y install sbcl")
+(defprop sbcl-available :posix ()
+  (:check
+   (zerop (mrun :for-exit "command" "-v" "sbcl")))
+  (:apply
+   (typecase (class-of (get-hostattrs-car :os))
+     (os:debianlike
+      (ignoring-hostattrs (apt:installed "sbcl")))
+     (t
+      (failed-change "Do not know how to install SBCL on this OS.")))))
+
+(defmethod establish-connection ((type (eql :sbcl)) remaining &key)
+  (sbcl-available)
   (request-lisp-systems)
   (upload-all-prerequisite-data)
   (inform t "Waiting for remote Lisp to exit, this may take some time ... ")
diff --git a/src/connection/sudo.lisp b/src/connection/sudo.lisp
index 3c7c633..5e2dbf9 100644
--- a/src/connection/sudo.lisp
+++ b/src/connection/sudo.lisp
@@ -34,8 +34,8 @@
 ;; passwords needed for establishing the remaining hops.  Depending on how the
 ;; connection type feeds instructions to the remote Lisp image, this may
 ;; involve writing your sudo password to a file under ~/.cache on the machine
-;; which runs the remote Lisp image.  At least :debian-sbcl avoids this by
-;; sending your password in on stdin.
+;; which runs the remote Lisp image.  At least :sbcl avoids this by sending
+;; your password in on stdin.
 
 ;; TODO Let's require the user pass :PASSWD or :NOPASSWD to indicate whether
 ;; we'll query prerequisite data sources and always try to send a password on
diff --git a/src/data/asdf.lisp b/src/data/asdf.lisp
index 2d61c49..51ac344 100644
--- a/src/data/asdf.lisp
+++ b/src/data/asdf.lisp
@@ -21,14 +21,13 @@
 ;; could we have both :asdf-monolithic and :asdf-something_else where in the
 ;; latter we filter out the names of systems already known to be available on
 ;; the remote side, so those don't need to be uploaded?  for example, the
-;; :debian-sbcl connection type can try to install them with apt on the remote
-;; side, then ask asdf for a concatenated source for everything excluding
-;; those.  if asdf can't be asked to do that, maybe we can ask it to produce
-;; one file per system, and then we eliminate those we don't want and
-;; concatenate the result ourselves.  maybe we can create a fake system object
-;; based on the real one, remove some deps from it according to a known
-;; mapping of systems to Debian package names, then ask asdf to concatenate
-;; that system
+;; :sbcl connection type can try to install them with apt on the remote side,
+;; then ask asdf for a concatenated source for everything excluding those.  if
+;; asdf can't be asked to do that, maybe we can ask it to produce one file per
+;; system, and then we eliminate those we don't want and concatenate the
+;; result ourselves.  maybe we can create a fake system object based on the
+;; real one, remove some deps from it according to a known mapping of systems
+;; to Debian package names, then ask asdf to concatenate that system
 
 (defmethod register-data-source ((type (eql :asdf)) &key)
   (cons #'asdf-data-source-check #'get-path-to-concatenated-system))
diff --git a/src/package.lisp b/src/package.lisp
index 856399d..b8fad64 100644
--- a/src/package.lisp
+++ b/src/package.lisp
@@ -198,9 +198,6 @@
   (:use #:cl #:consfigurator #:alexandria)
   (:export #:local-connection))
 
-(defpackage :consfigurator.connection.debian-sbcl
-  (:use #:cl #:consfigurator))
-
 (defpackage :consfigurator.connection.chroot
   (:use #:cl #:consfigurator #:cffi))
 
@@ -272,6 +269,11 @@
 	   #:uses-local-cacher
 	   #:standard-sources.list))
 
+(defpackage :consfigurator.connection.sbcl
+  (:use #:cl #:consfigurator)
+  (:local-nicknames (#:os  #:consfigurator.property.os)
+		    (#:apt #:consfigurator.property.apt)))
+
 (defpackage :consfigurator.property.user
   (:use #:cl #:consfigurator)
   (:local-nicknames (#:os  #:consfigurator.property.os))