On Sun, May 19, 2013 at 12:49:08PM -0700, Jonathan Nieder wrote: > unblock 708051 by 611929,611930 > quit > > Julian Gilbey wrote: > > On Sun, May 19, 2013 at 11:34:01AM -0700, Jonathan Nieder wrote: > > >> In the meantime, the usual way to use /var/cache/git is to put > >> symlinks there, though I realize that's not very satisfying. > > > > Quite! But again, the symlinks won't be recreated automatically, so > > it's still not ideal. > > Maybe that suggests a way to make a smooth transition: > > 1. preinst installs symlinks /var/lib/git/* -> /var/cache/git/* > 2. updated conffiles refer to /var/lib/git > 3. NEWS.Debian helps admins move the data to /var/lib/git
That could work, indeed. Though I would recommend /srv/git instead of /var/lib/git, as that is the directory recommended by the git documentation. Also, moving data around like this automatically has to obviously be done carefully, in case there is already data there. Perhaps a better way could be to have a debconf question asking the sysadmin whether they wish the data to be moved? It's messy, but how about something like this as a first stab: (1) Preinst: debconf question asking whether they would like their data moved to /srv/git, if being upgraded from a certain range of package versions. Also record the md5sums or sha1sums of the relevant conffiles. (2) Have new conffiles which refer to /srv/git (3) During the postinst, if the following condition holds: (the md5sum of the old conffile recorded in the preinst = the md5sum of the previous version of the package's conffile) AND (the md5sum of the current conffile = the md5sum of the current version of the package's conffile) AND (the sysadmin did not request their data to be moved or the move was unsuccessful) then edit the conffile to replace "/srv/git" with "/var/cache/git" That way, the sysadmin is given a chance to do the migration automatically, but if they do not wish to do so, and the conffile has been automatically upgraded, then it is reverted to the /var/cache/git directories, and will therefore not be automatically upgraded again. Julian -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
