[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#208011: [PROPOSAL] UTF-8 encoding for debian/control


        Ooops, forgot to CC the onjection to the bug report.

On Fri, 5 Sep 2003 22:56:07 +0200, Denis Barbier <barbier@linuxfr.org>

> On Mon, Sep 01, 2003 at 11:03:48PM -0500, Manoj Srivastava wrote:
>> On Mon, 1 Sep 2003 23:29:38 +0200, Denis Barbier
>> <barbier@linuxfr.org> said:
>> > Anyway I fail to see which problems arise with this proposal,
>> > could someone enlighten me?
>> This has been brought up before. The control fields should not
>> contain charsets that can't yet be handled by the packaging tools;
>> policy should follow, not lead, the tools and design, for the most
>> part. Policy is not the place to try out design; it is supposed to
>> document mature practices, and information about practices required
>> for package integration.

> You wrote in #127809 about the 'Enhances' field:

>> Policy mentions enhances as a means of declaring a dependency
>> relationship. It does not say that it shall be paid any attention
>> to by dpkg, apt, and friends.

> We are requesting that when 8-bit characters are used, they should
> be UTF-8 encoded.  We do not say that dpkg, apt, and friends have to
> recode these characters when processing these data.

        The major difference, which you have obviously missed, is that
 by design, any new and unknown fields are ignored by dpkg and
 friends; but they are supposed to handle and display control fields
 Since they are so constrained, the encoding of these fields should
 not be anything but ascii, until they tools are changed.

>> In time, support for this field shall come in the tools. In the
>> meanwhile, the field functions well enough to let humans know that
>> some package enhances the functionality of some other package. I
>> fail to see how that can be considered negative.

> Hey, you were on crack?  Repeat after me:

        One of the abilities required to bring changes to policy is
 the ability to deal with your fellow developer, and convince them of
 the validity of your proposal.

        Consider this, then, a formal objection to this proposal.

        Since the policy process is designed to seek near consensus, I
 think that this proposal is now dead in the water, given the
 objections this has received.

> Anyway same here, packaging tools will handle UTF-8 encoded fields
> later.  But having non UTF-8 data will make this support harder,
> because tools will have to deal with invalid multi-byte sequences.

        Right. So any non ascii data should be deemed illegal,
 including utf-8.

 signing this since this is a formal objection

Manoj Srivastava   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Attachment: pgpAzm2_EfEg9.pgp
Description: PGP signature

Reply to: