On Fri, 5 Sep 2003 22:56:07 +0200, Denis Barbier <barbier@linuxfr.org> said: > 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: > POLICY IS NOT THE PLACE TO TRY OUT DESIGN 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. manoj signing this since this is a formal objection -- "Anyone who has never made a mistake has never tried anything new." Albert Einstein Quotes On People and Life: 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:
pgplEiIW7CPQv.pgp
Description: PGP signature