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).