[Pkg-mailman-hackers] Bug#339059: mailman: Mailman/debconf forgets answer to language list question at install time

[Bernhard Schmidt]

control: found -1 1:2.1.22-1

Hi,

> > I can not judge the severity of this ug, but it is already open for a  
> > long time...
> 
> /var/lib/dpkg/info/mailman.config contains:
> --8<---------------cut here---------------start------------->8---
> # This script will be invoked by apt-get 2 times in a row, once when
> # preconfiguring the package and a second time just before running the
> # postinst script.  OTOH when installing the package with dpkg or when
> # reconfiguring the package, it runs only once.
> #
> # It scans all mailing lists on a system for used languages which may
> # be quite time consuming on systems with many lists; hence we better
> # avoid to run that scan twice in a row.
> # 
> # The debconf template mailman/used_languages holds the result of the
> # scan but is never presented to the user, instead its scanned flag
> # indicates if it holds a fresh value and is reset by the postinst,
> # while its seen flag is mainly used for cosmetical reasons to mark
> # processed values in debconf-show output.
> 
> db_get mailman/used_languages || true
> used_languages="${RET}"
> db_fget mailman/used_languages scanned || true
> scanned="${RET}"
> 
> if ! which list_lists >/dev/null 2>&1; then
>   # For 1st time installers there is no used language.
>   db_set  mailman/site_languages "en"
>   db_set  mailman/used_languages ""
>   db_fset mailman/used_languages scanned false
> else
> [...]
> --8<---------------cut here---------------end--------------->8---
> 
> I guess that at installation time the if is true (there is no list at
> all) and thus mailman/site_languages is set by default without taking
> into consideration the interactive or preseeded choice.

This bug is still present in jessie/stretch/sid.

I'm by far no debconf expert, but I have just dropped the

  db_set  mailman/site_languages "en"

line above and the resulting package seems to the right thing. I don't
get the reasoning of this db_set there, since it is already set at this
point through a debconf dialogue and can't be empty.

Or can it by preseeding or another debconf frontend? In this case we
should probably check the content and only db_set it if empty.

Best Regards,
Bernhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-mailman-hackers/attachments/20160426/3001d662/attachment.sig>