Config::Model and package upgrades
This would be a shortish post about a proposal which has been for sometime doing the rounds to be a Debian Enhancement Proposal. The proposal is for handling of the configuration files during Package Upgrades which as of right now is not so great.
First of all it would be good if you read about configuration file. But that is only to get some background info. Put simply, whether you are in GNU/Linux or in any other OS‘es each program/package that you install in your system with your knowledge or not gets a conf file. To understand it in the Debian context you have to read the Debian wiki entry as well.
Now the problem is that the average computer user does not know nor care about this configuration files. Now a configuration file may have two types of info., part of the info. would be the initial state of the application/library whatever and part of the info. would be about user-facing changes/info. Now I don’t know about other platforms but in GNU/Linux this would be divided into two, one where most of the info. would be at /etc, /var/lib/dpkg/info/, /usr/share or some place like that while the other would be somewhere in the person’s home directory either under ~/.config or something similar. While the user changes can be easily done as they are under the control of the user, the /etc files usually need sysadmin access (i.e. root) and not done properly can break things or/and not work properly.
Now when you upgrade a package under any OS at times the configuration files may also need to be updated to take advantage of the bug-fixes and new features added to the application. While sysadmins on Enterprise systems are paid for stuff like this for the generic user it can be hard and confusing and its possible to make bad decisions. There is/are also questions of stale data and other things. If you didn’t make the changes you might not be able to take as much advantage of the new version of software you like and possibly may not get the best results.
Before we get into the nitty-gritty of what the proposal is, let’s see a sample configuration file (called .conf in GNU/Linux) .
/etc/apt$ cat apt-file.conf
# Apt-file configuration file
# Substitutions are made as follows:
# host => remote hostname
# port => remote port
# uri => complete URI from sources.list
# path => path from /
# dist => the distribution name
# cache => path to the local cache dir
# dest => the destination file name inside the cache dir
# cdrom => cdrom mount point
# Where are located Packages
destination = __dists__Contents-.gz
# common code blocks can be defined as variables and be used as $check_cmd, etc. later
check_cmd = ( ( gunzip -l "/_tmp" >/dev/null 2>&1 || (echo "File is not gzipped."; false) ) && mv "/_tmp" "/" 2>&1 )
error_cmd = ( rm -f "/_tmp"; echo "Can't get /dists//Contents-.gz" )
post_dl_cmd = $check_cmd || $error_cmd
# Fetch methods using diffindex-download:
# -i : ignore missing files
# -q : be quiet
# -n : download full file if more than patches would be necessary
http = diffindex-download -i "/dists//Contents-.gz" /
https = diffindex-download -i "/dists//Contents-.gz" /
ftp = diffindex-download -i "/dists//Contents-.gz" /
# In debtorrent URLs, we have to replace 'debtorrent' by 'http', and we always download the full file
debtorrent = diffindex-download -i -n 0 "http://:/dists//Contents-.gz" /
ssh = scp -P "@://dists//Contents-.gz" "/_tmp" && $post_dl_cmd
rsh = rcp -l "://dists//Contents-.gz" "/_tmp" && $post_dl_cmd
file = cp "//dists//Contents-.gz" "/"
copy = cp "//dists//Contents-.gz" "/"
cdrom = echo "Put CDROM labeled in the cdrom device and press [ENTER]" > /dev/stderr ; read DUMMY ; mount ""; cp "/dists//Contents-.gz" "/" ; umount ""
# Schemes that might require user input on 'apt-file update'
# These will be skipped if -N is given
interactive = cdrom rsh ssh
The above is the configuration file for a package called apt-file.
Note: Simply put, the apt-file package searches for files within Debian packages using the CLI (command-line interface). It is useful to find out about a given filename from the mammoth Debian repository. If you know either the path of a binary/library or just a unique name its enough. For instance :-
$ apt-file search basePen
$ apt-file search /usr/bin/lsof
Just some examples of how it is used/can be used. It is a more versatile tool and can be used with help of regular expressions and all but that is a post for another day.
The configuration file which is posted a bit above maybe either complex for the average computer user or the user may have no contextual experience. I am not going to go into the details of what the configuration file does in this instance as that would take the attention away from the proposal at hand (even if the configuration file is interesting to me.)
Think of a scenario during an upgrade from a user’s point of view, if the computer asks you what to do as in showing a diff and asking you to make a choice most of the users would have not an idea what to do. Even if you are patient and do have the idea you may not have the time to go through each line to make sense of the diff. Also many a times, the diff presented it might not make sense at the first glance as most of the diff utilities would only show the differences where they are and not the whole thing so it could be difficult or/and time-consuming to figure out things. Add to the fact most of the diff utilities are ugly for the average joe/eve. There are exceptions but those are exceptions and still if you want to make a particular diffing utility to be the default diff viewer you would have to make some effort. All in all, for the average joe/eve it becomes harder to do the right thing or even make sense of things.
This is a framework written in Perl which should make it easier to do any changes (hopefully, if manual intervention is needed.) As of right now, it is right now in the form of a Debian proposal which has not made it even to the draft stage.
While I’m slightly optimistic that this should be accepted and if accepted would be nice, it clearly has a still long way to go – Proposal – Draft – Accept/Reject – Release goal .
The best person to read about and know more about config::model is to check out Dominique Dumont’s blog . He is the developer of the tool/framework as well as one of the major initiators of the proposal as well.
It would be interesting to see if this works out, for if it does, many of the problems people go through today would not just happen. I do have few questions about how it would work in some real-world scenarios but I guess that would have to wait for another day.I do know of many individuals though and friends who have put their configuration files on github or gitorious to have backups as well as for issues which can happen after playing/tweaking around with conf files. There is also a mailing list and couple of Youtube Videos which could be used to understand all of this a whole lot better.
You could also see my next post which shares some of the issues which are being faced in the current environment/way of doing things as well .