Summary of the 2008-03-11 Packaging Committee meeting

[Michael Schwendt]

On Thu, 13 Mar 2008 23:27:03 +0100, Nicolas Mailhot wrote:

> Le jeudi 13 mars 2008 à 22:51 +0100, Michael Schwendt a écrit :
> 
> > I'd like to understand the goal/the purpose of permitting unusual
> > characters in RPM package file names and how it relates to i17n/l10n
> > and file names in general.
> 
> For the record: I care nothing for the rpm file name.

The rpm file name is at the frontier. It is displayed to the user by the
installer, by package tools, and it may need to be input at the
command-line or in graphical apps. If the name of a package contains
non-ASCII glyphs or consists solely of non-ASCII characters, there is no
"name" the user can refer to. It is a serious usability regression. It
also makes community support more difficult. Translation or transition is
needed to turn it into something recognisable. See unreadable command
file names in system scripts, e.g., would be a nightmare.

> No upstream is
> going to complain about the package file name. Upstreams are sensitive
> to their project name, which we unfortunately map into filenames when we
> generate rpms.

If upstreams are "sensitive", they choose a project name which, at the
implementation level, is compatible with their target group. If the
underlying file-system supports UTF-8, hardly anyone would care about
data files that use multi-byte characters. But the user interface is
what matters.

We do have policies already about using American English in spec files
as opposed to British English and other languages. Package descriptions
must be in US English, too, and other languages are secondary only.

What would happen during package review with an application that is
completely in German without any English message object files?

> > I have the feeling that at first the door
> > for package names with multi-byte characters is opened, and as a next
> > step, file names in packages will use multi-byte characters, too.
> 
> This ship has sailed long ago and our official policy already
> explicitely allows this. In fact it goes further: filenames MUST be
> UTF-8, so a latin-1 filename that goes beyond the core latin subset
> common to UTF-8 and latin-1 is forbidden.

Any ship can be sunk.

A policy can be revisited/refined, because non-ASCII glyphs in file names
are a problem in a default setup that doesn't display them correctly and
that requires extra efforts to enter them. There are even characters that
display as whitespace or boxes in various terminals/applications and
turn into something else when using a different font:

# service ŧŧŧŧ start
Starting ŧŧŧŧ services:                                     [  OK  ]

In xterm that name displays as white-space, in Emacs with interleaved
white-space, in Sylpheed without white-space.

> > One
> > could also add non-English comments to spec files and source code
> > and justify it with the number of non-English Fedora contributors.
> 
> We already ship lots of code commented in other languages than English
> (for example, OO.o IIRC) so this ship also sailed a long time ago.

That's still only due to its Star Office history, isn't it? Proprietary
code developed by the Lüneburg/Hamburg, Germany, based Star Division, and
only much later open-sourced after the acquisition by Sun. Surely there
are other projects, which had started with non-English comments and
documentation before expanding to work with a global developer and user
community and a common project language. If in the source code everything
other than the reserved keywords (as defined by the programming language)
is not in English, debugging and proof-reading becomes much more difficult
for someone who doesn't understand the non-English words that are used.
OSS projects are ill-advised if they hope for participation, but don't
use an international language.

> I'm quite surprised people have such an English-centric view of an
> international project like Fedora.

Keeping English (AE and/or BE) as the project language helps against
community fragmentation.