Bug#718277: Conditional setting of gconftool alternative breaks when installing after removal

Emilio Pozuelo Monfort pochu at debian.org
Mon Jul 29 19:43:17 UTC 2013


Hi,

On 29/07/13 17:45, Margarita Manterola wrote:
> Package: gconf2
> Version: 3.2.5-1
> Severity: normal
> 
> Hi,
> 
> gconf2 uses update-alternatives to point /usr/bin/gconftool to
> /usr/bin/gconftool-2.  This is the relevant snippet:
> 
> if [ "$1" = configure ] && dpkg --compare-versions "$2" lt 2.26.2-4; then
>     update-alternatives \
>         --install /usr/bin/gconftool gconftool /usr/bin/gconftool-2 25 \
>         --slave /usr/share/man/man1/gconftool.1.gz gconftool.1.gz \
>                 /usr/share/man/man1/gconftool-2.1.gz
> fi
> 
> The problem with this is that if the user removes gconf2 the
> alternative gets correctly deleted, and then when re-installing it,
> the condition is not met (because when installing from the
> config-files state the postinst script receives the old package
> version as a parameter) and so the alternative is not recreated.
> 
> I'm not sure if the correct course of action is to check if the file
> is there instead of checking against the very old version, or checking
> if it's configuring from config-files instead of installed.  What I'm
> sure is that this causes issues when scripts expect /usr/bin/gconftool
> to be there, and it's not.

Another solution that should work fine is stop making gconftool an alternative
and provide it in the package itself. It's not like there's going to be a
gconftool-3 package anyway... :-)

Cheers,
Emilio




More information about the pkg-gnome-maintainers mailing list