APT install progress, varlink service, debconf and conffile prompts
(resending this due to address typo in the mailing list)
Hi.
Having recently looked at how to build an apt daemon, and also
in a quest to continue working on UX improvements, today I'd like
to talk about install progress and prompting.
The current situation is that we have two kinds of prompts:
1. debconf prompts
2. dpkg conffile prompts
Both of them get rendered by debconf or dpkg directly, as we attach
the pseudo terminal with standard input attached to the dpkg process
when we run it.
Obviously this does not work when running as a daemon, and the
verbosity of dpkg's output is concerning and detrimental to the
user experience.
Table of contents for the remainder:
1. debconf
1.1 communication flow for debconf
1.2 preconfiguration
2. conffile prompts
3. rendering of progress
debconf
=======
debconf gains a new 'varlink' frontend, that isn't actually a frontend
in the classical sense, but instead sends debconf prompts to a varlink
service operated by apt. APT will provide the name or file descriptor
of the varlink socket in an environment variable to it. We could
reuse the systemd socket activation protocol semantics.
APT will then either render the debconf prompt, or if it is running as
a daemon, forward this to the client to render.
communication flow for debconf
------------------------------
apt tool running directly and providing the service to debconf:
maintainer script -> debconf
\--varlink--> apt -> render
With a daemon/client:
maintainer script -> debconf
\--varlink--> aptd
\--varlink-->aptc -> render
With the possible extension for graphical frontends, the tail end
could look like:
\--varlink--> apt-proxy
\--varlink--> aptc -> render
(where apt proxy can respawn a new graphical frontend should the
active one day)
preconfiguration
----------------
debconf prompts can currently be pre-configured to some extend. I'd
love if we could move to a model where *all* debconf prompts are
pre-configured, such that once we start unpacking, all questions
are answered and packages are no longer _allowed_ to ask any.
Starting an upgrade and then doing something else only to come
back and find it popped up a prompt on you 10% through is not
a good user experience.
conffile prompts
================
conffile prompts need to be answered on dpkg's stdin. However,
we do get a notification about an active prompt on the status-fd.
Both existing solutions, aptdaemon and packagekit, use that
notification to display the message to the user and then write
the response to stdin.
We can do the same: We attach a pipe to the stdin of dpkg, and when
we run it and see a conffile prompt on status-fd, we render the
prompt and then forward the user response.
For new aptd, this again entangles varlink. I imagine if you
commit the transaction, you get a stream of "status" return
values, and one is "conffile prompt".
When seeing that, the client renders the prompt and then calls
a method on the aptd to answer it.
Rendering the conffile prompt ourselves allows us to render
it consistently with debconf prompts. In fact, we could extract
the conffiles first, and pre-configure all conffile prompts, or
introduce other value adds such as 3 way merging on top of dpkg.
rendering of progress
=====================
Aside from the rendering of prompts, another area closely related
is the rendering of progress. Instead of showing dpkg's output, that
output goes to a log file only.
I'm sure we're all tired of the huge wall of text that dpkg gives
us with "Preparing to unpack", "unpack", "setitng up", "Processing
triggers" lines flying past us.
I want to implement a radically simplified user experience, this
somewhat matches our download experience:
1. When we unpack a package, we render a line to the backlog indicating
the install of the package has started.
The lines are
Installing <package> <version>
Upgrading <package> <version> => <version>
Removing <package> <version>
2. At the bottom we maintain a running line of the currently active
status, or once finished a summary of the actions taken.
We can then go back up using the terminal features and manipulate the
past lines to add a DONE indicator when the package is configured.
Installing a 1.0
[ progress bar ] [X%] Installing a
Installing a 1.0
Installing b 2.0
[ progress bar ] [X%] Installing a
Installing a 1.0
Installing b 2.0
[ progress bar ] [X%] Configuring a
Installing a 1.0 DONE
Installing b 2.0
[ progress bar ] [X%] Configuring b
Installing a DONE
Installing b DONM
Installed 2 packages in <X> seconds.
If dpkg returns an error we include an error message with the output
from the last dpkg invocation:
Installed 2 packages in <X> seconds.
Error: Package installation failed, log follows:
Blah
Blah
Blah
Preparing to unpack ...
cp: cannot stat 'x': No such file or directory
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
Reply to: