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>

3 files changed, 13 insertions, 14 deletions

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)