Package: localepurge Version: 0.6.3 Severity: normal Dear Maintainer,
I just ran "dpkg-reconfigure localepurge" after having previously edited /etc/locale.nopurge by hand, and found the experience fairly confusing. Rather than offering the current settings from /etc/locale.nopurge as the default choices, it offered what I can only assume to be the values I chose the last time I configured it using the debconf interface. Then, after I'd gone through all the options, I was given what I now know to be a ucf(1) menu about a conflict between the "maintainer version" and the "local version" of /etc/locale.nopurge. So I picked the "open a shell" choice, planning to take a look in Emacs ... and was told that neither an X $DISPLAY nor a terminal was available, which was kind of confusing to me given that I was using an obviously terminal-based menu interface to decide what to do! (Then I noticed, with the help of "ps f -t <TTY-for-dpkg-reconfigure>", that ucf(1) and whiptail(1) were BOTH running, as siblings, and figured out that ucf must be using some kind of IPC to display the menu.) And, of course, when I eventually just installed the "maintainer version", the "-*- conf -*-" cookie that I had added for Emacs was gone. Summary of issues: ================== 1. The debconf script takes it's defaults from the debconf database, rather than parsing /etc/locale.nopurge 2. ucf(1) refers to the new locale.nopurge file as the "maintainer" version, even though it was just generated by the debconf script. 3. ucf(1) fails to open a shell when there is no $DISPLAY (when run under debconf with --debconf-ok) (I suppose the "-*- conf -*-" cookie thing is a temporary issue, owing to the fact that there was no stored "previous maintainer version" to use in a 3-way merge?) Analysis: ========= It doesn't look like anything can be done about issue 2 yet; ucf(1) would need a way to to customize the term it uses for <New File>. Issue 3 would go away if you used the old, crufty way of invoking ucf from a debconf script, but that would be crufty. I don't know how hard it would be to solve issue 1. Proposal ======== Add a note at the top of /etc/locale.nopurge that mixing manual editing and debconf-based editing leads to confusing results. (Of course, if you would rather fix the confusing results, or add a note now and fix the confusing results later, that'd work nicely as well.) Report ucf bugs for issues 2 and/or 3? (Perhaps cloning this one?) -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages localepurge depends on: ii debconf [debconf-2.0] 1.5.46 pn locales <none> ii procps 1:3.3.3-2 ii ucf 3.0025+nmu3 localepurge recommends no packages. Versions of packages localepurge suggests: pn bleachbit <none> pn debfoster <none> ii deborphan 1.7.28.8 -- debconf information: * localepurge/mandelete: false * localepurge/showfreedspace: true * localepurge/quickndirtycalc: true localepurge/remove_no: localepurge/none_selected: false * localepurge/nopurge: en, en.UTF-8, en@boldquot, en@quot, en_AG, en_AU, en_AU.UTF-8, en_BW, en_BW.UTF-8, en_CA, en_CA.UTF-8, en_DK, en_DK.ISO-8859-15, en_DK.UTF-8, en_GB, en_GB.ISO-8859-15, en_GB.UTF-8, en_HK, en_HK.UTF-8, en_IE, en_IE.UTF-8, en_IE@euro, en_IN, en_NG, en_NZ, en_NZ.UTF-8, en_PH, en_PH.UTF-8, en_SG, en_SG.UTF-8, en_US, en_US.ISO-8859-15, en_US.UTF-8, en_ZA, en_ZA.UTF-8, en_ZM, en_ZW, en_ZW.UTF-8 * localepurge/dontbothernew: true * localepurge/verbose: true -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
