Less interactive upgrades.
One of the minor annoyances in Debian is the prompting that goes on
during package upgrades. It's not the fact that the prompting
occurs... I like the fact that it doesn't silently redo the system
configuration... but rather the fact that it occurs thoughout the
upgrade process.
Debconf helps matters. It allows for configuration questions to be
asked the start of the installation process, which could then proceed
automatically. At least, that's the theory.
The problem I have is that dpkg keeps on prompting me as to the
disposition of config files I have changed. Don't get me wrong, I like
the fact that it asks me what to do... I just wish it would do it at
the start, and proceed cleanly through the upgrade without further
prompting.
Since it would be unkind of me to subject the list to the above
without proposing a solution, here's my answer to this:
- When apt runs to upgrade packages, it will call a new program (which
I plan to write) in the same way that it calls
dpkg-preconfigure. TNP would scan the list of upgraded packages,
looking for config files. (This scan could go rather fast, as it
only looks at config files, rather than having to unpack the
whole thing.) Where it finds changed config files (using the same
rules as dpkg) it will add them to a list.
The list will then be presented to the user, probably sorted by
package. Each of the changed config files will be there, and the
user will be able to select which ones he wishes to replace. (Other
options, like show a diff, edit file, and background TNP will be
given to allow the user to make an informed choice.) Once the user
is through with picking which config files he wants to replace, the
program will write the information to a well-known file and
terminate.
- The well known file will contain lines that look something like this:
/etc/config/file0 package keep b20482b9ffb207ba5448cedee746c690
The first entry is the config filename, the second is the name of
the package it's associated with. The third is whether the config
file is to be kept ("keep") or replaced ("replace"). I don't think
it will be used directly by dpkg, but it would come in handy in the
case of cluster upgrades, where a script might run over the file and
replace all the md5sums on the files marked "keep". But in normal
use it'll be ignored. The last field is the md5sum of the version of
the file that will be used. I'll get back to that in a second.
- Once the file is being appropriately created, dpkg will be modified
to optionally take as an argument to an option the name of the well
known file. It will read the information into a hash at the
start. Then when a configfile prompt would be displayed, the
filename and package are looked up to get a md5. If the md5 matches
that of the old conffile, it proceeds the same as if one said 'N' to
the prompt. If the md5 matches the new file, it's the same as
answering 'Y' to the prompt. If the md5 is different from both, or
the md5 can't be looked up, the normal prompt will be
displayed. (This covers the case of a config file changing between
TNP and dpkg runs.)
This, along with debconf and a program like debecho (which doesn't
exist, but if it did would allow logging of informational messages to
a file) would allow for unattended installations and upgrades, after
the initial Q&A session. I think that would be a real good thing to
have, especially if we don't lose flexability when it happens.
I'd like to know what people think about this... I'm considering
starting coding on this during spring break next week, and it'll use a
bit of infrastructure in common with ddiff. I'd also like to know if
there's a preferred textui toolkit for use during installs/upgrades,
or if I should just roll my own.
I'm interested in hearing comments, suggestions, flames, summer job
offers, package name ideas, etc... I would like to get going on this
by next week, however.
Oh, and for those who are wondering:
I've decided to work on this rather than bettering ddiff integration
because this is something that can work stand-alone to better the user
experience, while ddiff will require new or different archives to
achive maximum usefulness. (Ie, the diffs have to be stored
somewhere.) I'll be returning to ddiff once I finish this, which
should go rather quickly, and I'll probably do an ITP for ddiff before
them. (I have the packaging essentially done, but I want to wait to
hear back about some bug reports before a sponsored upload is done.)
Lastly, is there a more appropriate list than debian-devel for
announcing projects like this?
--
Tom Rothamel --------- http://onegeek.org/~tom/ ------- Using GNU/Linux
Writing from home, just outside Northport, NY.
The Moon is Waxing Gibbous (85% of Full).
Reply to: