> Thanks. btw, I'm assuming these issues also apply to the package in > unstable? If so then they should really be fixed there too.
Yes, once the solution is "definitive" i'll apply the changes to unstable, otherwise it will break on the upgrade. Openacs package has the same issues so it will be updated too. > + ucf --debconf-ok $localconfigtmp $localconfig || cp -f > $localconfigtmp $localconfig > > Under what circumstances might ucf fail in a way that would necessitate > the forced copying? None in particular, just thought it could be more robust that way. In case local ucf is broken somehow, dotlrn could install anyway. > + chmod 640 $localconfig > + chown www-data:www-data $localconfig > > This looks like it would overwrite any local changes made to the > permissions? Yes, should i check if the file already exists and respect the existing permissions? > + rm -f /etc/aolserver4/conf.d/dotlrn.tcl > /etc/aolserver4/conf.d/dotlrn.sh > + # Start aolserver after removal > + [ -f /etc/init.d/aolserver4 ] && invoke-rc.d aolserver4 start > > What's the logic here? If the intention is to make aolserver4 notice > that the configuration files have gone away then "restart" would > probably be more appropriate? There is a potential issue here though if > the service wasn't actually running before dotlrn was removed. I see, so could this be an acceptable replacement? [ -f /etc/init.d/aolserver4 ] && [ -f /var/run/aolserver4/dotlrn.pid ] && invoke-rc.d aolserver4 restart ...or this one, assuming /etc/init.d/aolserver4 exists if there is a /var/run/aolserver4/dotlrn.pid file: [ -f /var/run/aolserver4/dotlrn.pid ] && invoke-rc.d aolserver4 restart > + # If the file was not modified by the user, then we can restore > + # it to its initial state (before running postinst and modify it > + # with debconf values) by deleting the modified lines. > + # > + # See Bug #688435 > + # > + if dpkg --compare-versions "$2" le "2.5.0+dfsg-6+wheezy1" > + then > + # Reset config.tcl to its primordial state > + sed -i '/set db_host/,/set db_user/d' /etc/dotlrn/config.tcl > + fi > > If the file had been modified by the user, you've just overwritten their > changes? I guess that would already have happened with the forced > debconf overwrite. :-( Only the changes between the lines "## Debconf changes (DO NOT EDIT BYHAND) ##" and "## End Debconf Changes ###################" are overwritten. The idea behind this was: - If the file wasn't modified by the user, then the upgrade is performed smoothly and the new config.local file is generated with the old debconf values. - If the "debconf block" was modified by hand by the user, then overwrite the changes with the debconf ones in config.local. It should be ok, because there was a warning about not doing that. - If another block of the file was modified by the user, then prompt him about the changes, as with any other config file. Now, i realise that i'm assuming that the user should only use debconf to modify these changes (database settings, via package reconfigure), should i give the user the chance to edit this settings by hand, checking them on preinst and replacing the current debconf values with the modified ones? Thanks again! Kind regards, Héctor -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
