Bug#361872: debconf-copydb: Trashes debconf database in /target
On Mon, Jun 19, 2006 at 08:57:02PM +0200, Steinar H. Gunderson wrote:
> On Mon, Jun 19, 2006 at 01:42:53PM -0400, Joey Hess wrote:
> > The easiest way would probably be to not track the information and store
> > (and output) the field as utf-8 without doing any transcoding. This is
> > not exactly what debconf does, but fields that do not define an encoding
> > are basically using an undefined encoding and it's ok if cdebconf
> > assumes it's really utf-8. If this causes a mojibake then the right way
> > to fix it is to make the package define an encoding.
>
> After some discussion on IRC, here's the updated patch.
>
> --- cdebconf-0.102.orig/src/template.c 2005-09-21 19:07:46.000000000 +0200
> +++ cdebconf-0.102/src/template.c 2006-06-19 20:54:35.000000000 +0200
> @@ -354,7 +354,7 @@
> free(orig_field);
> return NULL;
> }
> - cp = strstr(altlang, ".UTF-8");
> + cp = strcasestr(altlang, ".UTF-8");
I am not sure that this is desirable, next time you will encounter "utf8"
instances, and maybe other names too (except that I cannot find another
one ;))
> + /* Plain debconf supports undefined character sets, on the
> + form "Description-nb_NO: ", which is valid if the text is
> + ASCII (but debconf still uses that syntax regardless of
> + validity if the application does not specify a character
> + set). To avoid losing these fields, we simply read them
> + in as if they were UTF-8 fields, as valid ASCII is always
> + valid UTF-8 as well.
Ditto, this is supported by debconf for compatibility reasons, but we
should try hard to get rid of undefined encodings wherever possible.
Denis
Reply to: