[Fedora-packaging] Re: UTF-8 package names
a.badger at gmail.com
Wed Feb 27 19:04:31 UTC 2008
Axel Thimm wrote:
> On Tue, Feb 26, 2008 at 06:52:24PM -0800, Toshio Kuratomi wrote:
>> Package names should follow upstream since attempting to transliterate or
>> translate upstream names can't be done sanely on our side. For things that
>> map easily into the ASCii set (diacritic/accented characters, for instance,
>> as found in latin-1) a transliterated Provides can be added to make
>> installation easier for ASCii-conditioned users but carrying this on to
>> other scripts is a losing proposition.
> We violate this rule with capitalization,
> python/perl/php/.... packages and what not and we'll stick with an
> upstream's name that seems to want to ship its project only is certain
You raise some good points. Why do we change upstream WRT
capitalization? Probably usability. What will we do if capitalization
matters? (ie: foobar and FooBar are separate projects) Not approve a
package that has a conflicting name and try to get either or both
projects to rename upstream. If the packages weren't changed upstream
(because, says upstream, FooBar and foobar are plainly different names)
what would we do? This is an unknown that seems very relevant here.
OTOH, there is a single straightforward, non-controversial mapping from
uppercase ASCii to lowercase ASCii. Transliteration and transcription
from other scripts is not so blessed. So the rationale for wanting to
ban Unicode could be the same as wanting to ban capitalization but the
ramifications are very different.
Changing module names is interesting. Speaking for python we do two things:
1) We use "import foo" to determine what the package's upstream name is
rather than the name of the tarball. I don't consider this changing the
name as there are several equally valid ways to determine what the
upstream name is so we've just standardized on one.
2) We prepend "python-" to the name in most cases. This is partially
categorization and partially a namespacing issue. Categorization is
changing the name to make it easier for users to recognize the purpose
of a package. python-turboflot doesn't need the "python-" for anything
other than making *people* aware that turboflot is a python module.
Namespacing is a valid issue, though. python-json != php-json !=
perl-json even if they all use the equivalent of "import json" and
distributed their binaries in tarballs called json-1.0.tar.gz.
I think justifying banning unicode with the module namespace as a
precedent is illogical. If anything, converting unicode characters in a
user's chosen script to a ASCii-ization is removing a means of
categorizing the package by sight. It will also lead to more namespace
collisions rather than less.
> I would instead propose a rule that says "if the transliteration to
> ASCII can't be done by the packager, he should contact upstream to
> provide one and use that".
If you said that upstream should always be in charge of transliterating
I think this rule would be better. To use an example that people might
know from non-computer life what if upstream named their package 北京?
One distribution might feel perfectly confident transliterating that as
beijing while another one uses peking. Having upstream manage
transliteration pushes the decision to the correct level to coordinate
and avoid confusion.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: OpenPGP digital signature
More information about the Fedora-packaging