[Pkg-tcltk-devel] Bug#681016: [release.debian.org] unblock: dotlrn/2.5.0+dfsg-8

[Hector Romojaro]

> 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