Bug#701081: debian-policy: mandate an encoding for filenames in binary packages

[Charles Plessy <plessy@debian.org>]

Le Sat, Mar 16, 2013 at 10:58:11PM +0100, Bill Allombert a écrit :
> On Sat, Mar 09, 2013 at 10:51:45AM +0900, Charles Plessy wrote:
> > 
> > I think that it emerges from the discussion that there are good uses of
> > Unicode, and that somebody would need to step up and ensure that a dozen of
> > packages are corrected if we were to restrict further the encoding of file
> > names.  Moreover, there seems to be a good self-discipline, and Unicode is
> > not used in paths that are central on non-Unicode systems.
> 
> I have yet to see any good use of 8bit finename in Debian binary packages.

Hi Bill,

I undestand that you are critical with the idea of allowing 8bit file names.
I am sorry if my brief summary could have given the impression that there
is no "good" reason to refrain from using 8bit file names as well.

At that point of the discussion, I do not see new arguments being added.  We
therefore need to move towards the resolution of this bug.  I see the
possible outcomes.

 a) Status quo: currently there is no policy, and we can decide to not write
    any policy instead of taking one that does not reach consensus. (not my
    favorite).

 b) Disallow non-UTF-8 encodings.  This requires little work (which I started),
    answers to the original issue raised in this bug (there is no policy), and
    does not preclude further restrictions if there is consensus for doing so.

 c) Disallow non-ASCII encodings.  This requires more work, and I am fairly
    confident to write that if nobody takes action and leads the correction of
    the affected packages in the archive, nothing will happen and we will not
    be able to make the corresponding change in the Policy.

If we would tackle the issue with a Condorcet vote, I think that b) would
be chosen, unless there are worries that once we reach b) it will not be
possible to propose c) anymore.  Personally, I trust that Debian's do-ocracy
will work well, and that if there are developers determined to propose c)
and make it happen if our community sees a benefit, being in the b) state
will be a bonus, not a drawback.  I nevertheless need to add that I personally
think that b) is better than c), as shown by the summary that I wrote with
too much bias (sorry again).

Shall we go for b) ?

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan