Meeting minutes and full logs of the packaging committee meeting which occurred on 2008-03-11 are online:
http://fedoraproject.org/wiki/Packaging/Minutes http://fedoraproject.org/wiki/Packaging/Minutes20080311
Two issues are pending FESCO ratification:
* http://fedoraproject.org/wiki/PackagingDrafts/OCaml
* http://fedoraproject.org/wiki/PackagingDrafts/Tcl
Other business:
* http://fedoraproject.org/wiki/PackagingDrafts/OpenOffice.orgExtensions * Further questions were posed and will be relayed to the draft submitter.
* Ban unicode in package names (no draft submitted) * Not accepted
- J<
Jason L Tibbitts III wrote:
- Ban unicode in package names (no draft submitted)
- Not accepted
Oops... The example of such an unicode name used is "écolier-fonts" .
Then consider any user in non-latin1 locale. For example, my locale is Russian. I have no "é" on my keyboard...
Well, I can use cut and paste, when I have a mouse and the text is already shown on my desktop. But what I have to do, when use just the cmdline interface? IOW, without any GUI -- just the Linux console, or remote ssh session? How can I fill the "é" character then?
It seems that the only way to operate with such a filename is to use shell wildcards: "rpm -qa ?colier-fonts" etc.
Does it mean, that the command line interface as well as any other non-GUI core applications are now deprecated? ;)
On Wed, 2008-03-12 at 14:29 +0300, Dmitry Butskoy wrote:
Jason L Tibbitts III wrote:
- Ban unicode in package names (no draft submitted)
- Not accepted
Oops... The example of such an unicode name used is "écolier-fonts" .
Then consider any user in non-latin1 locale. For example, my locale is Russian. I have no "é" on my keyboard...
You are reiterating my mantra, which had been the reason for me to propose banning unicode in package names.
Unfortunately, my FPC colleagues seem to be keen on shooting themselves into their foot and to be keen on letting Fedora's usability to regress further.
Well, I can use cut and paste, when I have a mouse and the text is already shown on my desktop. But what I have to do, when use just the cmdline interface? IOW, without any GUI -- just the Linux console, or remote ssh session? How can I fill the "é" character then?
It seems that the only way to operate with such a filename is to use shell wildcards: "rpm -qa ?colier-fonts" etc.
Does it mean, that the command line interface as well as any other non-GUI core applications are now deprecated? ;)
Apparently that's what Fedora is heading to - Too many kids around, whio have grown up with Win, I suppose.
Ralf
Has anyone checked whether the many sites that mirror Fedora packages can even handle unicode / non-7-bit-ASCII names correctly?
Rich.
Richard W.M. Jones wrote:
Has anyone checked whether the many sites that mirror Fedora packages can even handle unicode / non-7-bit-ASCII names correctly?
It is better to check the primary sites first (as well as the primary sysadmins ;) )
What about such unicode names (try to work with them from the cmdline shell):
nothing-1.0-1.rpm ничто-1.0-1.rpm τιποτα δεν-1.0-1.rpm 没有什么东西-1.0-1.rpm
1.0-1.rpmلا شيء
(the last one is a little broken -- Arabic uses right-to-left direction... )
~buc
On Wed, 12 Mar 2008 14:53:28 +0300, Dmitry Butskoy wrote:
Richard W.M. Jones wrote:
Has anyone checked whether the many sites that mirror Fedora packages can even handle unicode / non-7-bit-ASCII names correctly?
It is better to check the primary sites first (as well as the primary sysadmins ;) )
What about such unicode names (try to work with them from the cmdline shell):
nothing-1.0-1.rpm ничто-1.0-1.rpm τιποτα δεν-1.0-1.rpm 没有什么东西-1.0-1.rpm
For the last two, the glyphs don't display correctly at all in a virtual console. Not in Emacs either. In Emacs (and likely due to an incomplete font), the last line gives a box for the 4th character.
A blocker-criterion in my point of view.
Having to find and set a proper font before being able to display the proper glyphs used in [RPM] filenames, reduces usability too much. It feels a lot like those bad books, where the translator also translated the names of system commands, reserved identifiers, or header names, for example.
Michael Schwendt wrote:
nothing-1.0-1.rpm ничто-1.0-1.rpm τιποτα δεν-1.0-1.rpm 没有什么东西-1.0-1.rpm
For the last two, the glyphs don't display correctly at all in a virtual console. Not in Emacs either. In Emacs (and likely due to an incomplete font), the last line gives a box for the 4th character.
A blocker-criterion in my point of view.
Having to find and set a proper font before being able to display the proper glyphs used in [RPM] filenames, reduces usability too much. It feels a lot like those bad books, where the translator also translated the names of system commands, reserved identifiers, or header names, for example.
Sounds like you see different results for the fourth one. I see: http://members.iinet.net.au/~timmsy/list-links/rpm.name_glyphs.png
I have no idea howe I could possible type 2 or 3 ?
DaveT.
On Wed, 2008-03-19 at 22:42 +1100, David Timms wrote:
nothing-1.0-1.rpm ничто-1.0-1.rpm τιποτα δεν-1.0-1.rpm 没有什么东西-1.0-1.rpm
I have no idea howe I could possible type 2 or 3 ?
$ ls -l total 12 -rw-rw-r-- 1 seg seg 0 2008-03-19 10:30 τιποτα δεν-1.0-1.rpm -rw-rw-r-- 1 seg seg 0 2008-03-19 10:29 ничто-1.0-1.rpm -rw-rw-r-- 1 seg seg 0 2008-03-19 10:37 没有什么东西-1.0-1.rpm
$ touch $'\316\264\316\265\316\275-1.0-1.rpm'
$ ls -l total 16 -rw-rw-r-- 1 seg seg 0 2008-03-19 10:39 δεν-1.0-1.rpm -rw-rw-r-- 1 seg seg 0 2008-03-19 10:30 τιποτα δεν-1.0-1.rpm -rw-rw-r-- 1 seg seg 0 2008-03-19 10:29 ничто-1.0-1.rpm -rw-rw-r-- 1 seg seg 0 2008-03-19 10:37 没有什么东西-1.0-1.rpm
$ LANG=en_US.latin1 ls -b \316\264\316\265\316\275-1.0-1.rpm \317\204\316\271\317\200\316\277\317\204\316\261\ \316\264\316\265\316\275-1.0-1.rpm \320\275\320\270\321\207\321\202\320\276-1.0-1.rpm \346\262\241\346\234\211\344\273\200\344\271\210\344\270\234\350\245\277-1.0-1.rpm
QED RTFM HAND
Callum Lerwick wrote:
$ ls -l total 12 -rw-rw-r-- 1 seg seg 0 2008-03-19 10:30 τιποτα δεν-1.0-1.rpm -rw-rw-r-- 1 seg seg 0 2008-03-19 10:29 ничто-1.0-1.rpm -rw-rw-r-- 1 seg seg 0 2008-03-19 10:37 没有什么东西-1.0-1.rpm
$ touch $'\316\264\316\265\316\275-1.0-1.rpm'
$ ls -l total 16 -rw-rw-r-- 1 seg seg 0 2008-03-19 10:39 δεν-1.0-1.rpm -rw-rw-r-- 1 seg seg 0 2008-03-19 10:30 τιποτα δεν-1.0-1.rpm -rw-rw-r-- 1 seg seg 0 2008-03-19 10:29 ничто-1.0-1.rpm -rw-rw-r-- 1 seg seg 0 2008-03-19 10:37 没有什么东西-1.0-1.rpm
$ LANG=en_US.latin1 ls -b \316\264\316\265\316\275-1.0-1.rpm \317\204\316\271\317\200\316\277\317\204\316\261\ \316\264\316\265\316\275-1.0-1.rpm \320\275\320\270\321\207\321\202\320\276-1.0-1.rpm \346\262\241\346\234\211\344\273\200\344\271\210\344\270\234\350\245\277-1.0-1.rpm
Sure. It is possible! Perhaps it looks not so convenient, but the CLI enthusiasts should enjoy it, at least because they are CLI enthusiasts </sarcasm>
~buc
David Timms wrote:
Michael Schwendt wrote:
nothing-1.0-1.rpm ничто-1.0-1.rpm τιποτα δεν-1.0-1.rpm 没有什么东西-1.0-1.rpm
For the last two, the glyphs don't display correctly at all in a virtual console. Not in Emacs either. In Emacs (and likely due to an incomplete font), the last line gives a box for the 4th character.
A blocker-criterion in my point of view.
Having to find and set a proper font before being able to display the proper glyphs used in [RPM] filenames, reduces usability too much. It feels a lot like those bad books, where the translator also translated the names of system commands, reserved identifiers, or header names, for example.
Sounds like you see different results for the fourth one. I see: http://members.iinet.net.au/~timmsy/list-links/rpm.name_glyphs.png
I have no idea howe I could possible type 2 or 3 ?
badger> LANG=C ls -b *.rpm \346\262\241\346\234\211\344\273\200\344\271\210\344\270\234\350\245\277-1.0-1.rpm badger> rm $'\346\262\241\346\234\211\344\273\200\344\271\210\344\270\234\350\245\277-1.0-1.rpm'
Annoying, yes. Impossible, no.
-Toshio
Ralf Corsepius wrote:
Well, I can use cut and paste, when I have a mouse and the text is already shown on my desktop. But what I have to do, when use just the cmdline interface? IOW, without any GUI -- just the Linux console, or remote ssh session? How can I fill the "é" character then?
It seems that the only way to operate with such a filename is to use shell wildcards: "rpm -qa ?colier-fonts" etc.
Does it mean, that the command line interface as well as any other non-GUI core applications are now deprecated? ;)
Apparently that's what Fedora is heading to - Too many kids around
Even at "Packaging Committee meeting" ??...
~buc
On Wed, 2008-03-12 at 14:57 +0300, Dmitry Butskoy wrote:
Ralf Corsepius wrote:
Well, I can use cut and paste, when I have a mouse and the text is already shown on my desktop. But what I have to do, when use just the cmdline interface? IOW, without any GUI -- just the Linux console, or remote ssh session? How can I fill the "é" character then?
It seems that the only way to operate with such a filename is to use shell wildcards: "rpm -qa ?colier-fonts" etc.
Does it mean, that the command line interface as well as any other non-GUI core applications are now deprecated? ;)
Apparently that's what Fedora is heading to - Too many kids around
Even at "Packaging Committee meeting" ??...
I would not claim this applies on FPC in general, but wrt. this matters, I can't deny feeling so.
Certain members denied UTF-8 to impose usability problems and redirected discussion to "compose keys" and "GUI tools", so ... shall they get what they want ...
I had wanted to prevent harm from Fedora, but I failed :/
May-be these people need to trip these issues themselves to understand why this is a usability regression, and why I consider allowing utf-8 in package file names to be short-sighted.
Ralf
Ralf Corsepius wrote:
On Wed, 2008-03-12 at 14:29 +0300, Dmitry Butskoy wrote:
Jason L Tibbitts III wrote:
- Ban unicode in package names (no draft submitted)
- Not accepted
Oops... The example of such an unicode name used is "écolier-fonts" .
Then consider any user in non-latin1 locale. For example, my locale is Russian. I have no "é" on my keyboard...
You are reiterating my mantra, which had been the reason for me to propose banning unicode in package names.
Unfortunately, my FPC colleagues seem to be keen on shooting themselves into their foot and to be keen on letting Fedora's usability to regress further.
Well, I can use cut and paste, when I have a mouse and the text is already shown on my desktop. But what I have to do, when use just the cmdline interface? IOW, without any GUI -- just the Linux console, or remote ssh session? How can I fill the "é" character then?
It seems that the only way to operate with such a filename is to use shell wildcards: "rpm -qa ?colier-fonts" etc.
Does it mean, that the command line interface as well as any other non-GUI core applications are now deprecated? ;)
Apparently that's what Fedora is heading to - Too many kids around, whio have grown up with Win, I suppose.
You guys are blowing this way out of proportion, it would seriously help to read the actual irc log. Also its too bad that it wasn't made clear in the summary that this was not on the agenda, but only something discussed during the free discussion phase at the end of the meeting.
AFAIK the whole FPC does not want to allow unicode names at the moment, but we don't want to forbid them for now and ever on also, which is what the current proposal basicly says.
What would be good to have is a more balanced proposal which: 1) Explains that for now unicode filenames, and thus packagenames are forbidden because we don't know if our infrastructure is ready 2) Lays out a plan (involving for example a test repo with unicode filenames, and asking a few mirrors to try and sync to this in a _separate_ cronjob) for making sure that our infrastructure gets fixed to handle this. 3) Calls for a revisit of this issue once the infra is ready.
And then, when we reach step 3 (like with F-12), we can discuss all the perceived usability issues, atm unicode package / filenames should simply not be used!
Regards,
Hans (speaking for myself, not the FPC)
"HdG" == Hans de Goede j.w.r.degoede@hhs.nl writes:
HdG> Also its too bad that it wasn't made clear in the summary that HdG> this was not on the agenda, but only something discussed during HdG> the free discussion phase at the end of the meeting.
I listed the votes that were called. I tend not to include any additional commentary because I do not want to introduce any personal opinion into the summaries.
It is not uncommon that we address and indeed vote on something that was brought to us during the meeting. I don't really see what effect that has on the fact that a vote was called and the proposal did not pass.
If you have suggestions for the summary format, we can consider them at the next meeting.
- J<
On 12 Mar 2008 11:42:22 -0500, Jason L Tibbitts III tibbs@math.uh.edu wrote:
If you have suggestions for the summary format, we can consider them at the next meeting.
I've a couple of suggestions for the packaging committee to consider in an effort to prevent this sort of flame damage in the future.
For items that are not on your committee's agenda for discussion, but come up during the meeting that as a group you don't feel are ready for a vote.... your committee might think about voting to table the issue until a formal proposal/community discussion is in place instead of voting yes/no. You then list the item as tabled and needing a formal proposal and community discussion period in your summary. Such summary items might produce a list discussion with much smaller pitchforks and much cooler torches.
You might even consider having a committee policy that any item that comes up in discussion that can't be unanimously agreed on by the end of that meeting automatically gets tabled until a formal, community vetted proposal gets put forward on a subsequent meeting agenda where you can do a formal vote.
-jef
On Wed, 2008-03-12 at 08:58 -0800, Jeff Spaleta wrote:
On 12 Mar 2008 11:42:22 -0500, Jason L Tibbitts III tibbs@math.uh.edu wrote:
If you have suggestions for the summary format, we can consider them at the next meeting.
Textform: "All package names must be encoded in 7-bit ASCII chars".
I've a couple of suggestions for the packaging committee to consider in an effort to prevent this sort of flame damage in the future.
For items that are not on your committee's agenda for discussion, but come up during the meeting that as a group you don't feel are ready for a vote.... your committee might think about voting to table the issue until a formal proposal/community discussion is in place instead of voting yes/no.
This already had happened - 2 weeks ago.
We had discussed this on the packaging list - Unfortunately with little results.
You then list the item as tabled and needing a formal proposal and community discussion period in your summary. Such summary items might produce a list discussion with much smaller pitchforks and much cooler torches.
You might even consider having a committee policy that any item that comes up in discussion that can't be unanimously agreed on by the end of that meeting automatically gets tabled until a formal, community vetted proposal gets put forward on a subsequent meeting agenda where you can do a formal vote.
-1
Your proposal equals closing down FPC, because hardly any decision in FPC is unanimous.
Ralf
On Wed, Mar 12, 2008 at 9:26 AM, Ralf Corsepius rc040203@freenet.de wrote:
Your proposal equals closing down FPC, because hardly any decision in FPC is unanimous.
My reading of events from this thread, the summary, and the minutes, was that this was something not put forward as an agenda item, and it came up as part of meeting discussion as new business during the meeting. Closer inspection of the irclog in this weeks minutes and I see that its holdover from last meetings business... I missed that the first time through. Apologizes. The minutes link for that previous meeting seems to be missing in the wiki.
My suggestions were aimed at how to handle the scenario of something coming up during the meeting that wasn't on the agenda for discussion..generally. If my reading of these events are wrong, as it appears it was, and this was something that was on the agenda for that meeting, then my suggestions aren't meant to apply. At no point was I suggesting that you need unanimous consent for all business, just for things that come up during a meeting.
So another suggestion for Jason, at least to me it clearer to me. In the summary, can you try to point out old business from a previous meeting that is being brought back for more discussion? You don't have to reference which meeting it was previously discussed at, but just knowing its old business helps with context.
-jef
On Wed, 2008-03-12 at 16:47 +0100, Hans de Goede wrote:
Ralf Corsepius wrote:
On Wed, 2008-03-12 at 14:29 +0300, Dmitry Butskoy wrote:
Jason L Tibbitts III wrote:
- Ban unicode in package names (no draft submitted)
- Not accepted
Oops... The example of such an unicode name used is "écolier-fonts" .
Then consider any user in non-latin1 locale. For example, my locale is Russian. I have no "é" on my keyboard...
You are reiterating my mantra, which had been the reason for me to propose banning unicode in package names.
Unfortunately, my FPC colleagues seem to be keen on shooting themselves into their foot and to be keen on letting Fedora's usability to regress further.
Well, I can use cut and paste, when I have a mouse and the text is already shown on my desktop. But what I have to do, when use just the cmdline interface? IOW, without any GUI -- just the Linux console, or remote ssh session? How can I fill the "é" character then?
It seems that the only way to operate with such a filename is to use shell wildcards: "rpm -qa ?colier-fonts" etc.
Does it mean, that the command line interface as well as any other non-GUI core applications are now deprecated? ;)
Apparently that's what Fedora is heading to - Too many kids around, whio have grown up with Win, I suppose.
You guys are blowing this way out of proportion,
I massively disagree, ... what you currently observe is negligible in comparison to the flame that I expect you to experience when this would hit the repos.
it would seriously help to read the actual irc log. Also its too bad that it wasn't made clear in the summary that this was not on the agenda, but only something discussed during the free discussion phase at the end of the meeting.
It had been discussed in FPC before (When you had not been member: 2 weeks ago), it had been discussed in bugzilla (écollier-fonts review), it had been discussed on the fedora-packaging list before (ca. 2 weeks ago).
AFAIK the whole FPC does not want to allow unicode names at the moment, but we don't want to forbid them for now and ever on also, which is what the current proposal basicly says.
What would be good to have is a more balanced proposal which:
- Explains that for now unicode filenames, and thus packagenames are forbidden because we don't know if our infrastructure is ready
- Lays out a plan (involving for example a test repo with unicode filenames, and asking a few mirrors to try and sync to this in a _separate_ cronjob) for making sure that our infrastructure gets fixed to handle this.
- Calls for a revisit of this issue once the infra is ready.
And then, when we reach step 3 (like with F-12), we can discuss all the perceived usability issues, atm unicode package / filenames should simply not be used!
I can only reiterate what I've said dozens of times before: The technical issues are irrelevant, because they are solvable - The usability issues matter.
Ralf
ons 2008-03-12 klockan 16:47 +0100 skrev Hans de Goede:
And then, when we reach step 3 (like with F-12), we can discuss all the perceived usability issues, atm unicode package / filenames should simply not be used!
RPMs will probably always need names that everyone can type. That limits it too Latin-1 (regardless of encoding) at most which is really not enough to make the extension of the allowed character set worthwhile.
Maybe RPMs need two or more names, first a technical one in simple ASCII and then one or several long ones in full Unicode. It could even include whitespace. Some thought need to go into separating translation and transcription, but that should be doable.
/abo
Alexander Boström wrote:
RPMs will probably always need names that everyone can type. That limits it too Latin-1 (regardless of encoding)
Please, note that "everyone" cannot type Latin1 .
There are enough countries in the World, where the Latin1 symbols are not used at all. Moreover, they did not use ASCII in their culture initially. ASCII came later, as a "symbols for the technical English", because this language are used for computers for the historical reasons (as well as the French is used in diplomacy).
IMHO the issue here is a lack of geography knowledge. Some people ("kids" in terms of Ralf :) ) actually think that it is possible to travell from US to Europe on a car... (without the ferry :) ). Hence it is not too surprisingly that they think that all the people in the World use latin1 ...
On Thursday 13 March 2008 14:44:04 Dmitry Butskoy wrote:
Some people ("kids" in terms of Ralf :) ) actually think that it is possible to travell from US to Europe on a car... (without the ferry :) ).
Although not practical it should be possible. ;-)
The problem with global warming is that the Artic Ocean will have the Northwest Passage ice freeduring the summer, around 2040. And then car travel will not be possible without using a boat. ;-)
http://en.wikipedia.org/wiki/Northwest_Passage
There is a similar Northeast passage: http://en.wikipedia.org/wiki/Northern_Sea_Route
tor 2008-03-13 klockan 17:44 +0300 skrev Dmitry Butskoy:
Alexander Boström wrote:
RPMs will probably always need names that everyone can type. That limits it too Latin-1 (regardless of encoding)
Please, note that "everyone" cannot type Latin1 .
Yes, one shouldn't have to type latin characters to use Fedora.
But if there's going to be a set of characters one have to be able to type to do technical things in Fedora (like doing "yum install") then [A-Za-z0-9] is a reasonable choice and that's also status quo.
/abo
On Thu, 13 Mar 2008 17:44:04 +0300, Dmitry Butskoy wrote:
Alexander Boström wrote:
RPMs will probably always need names that everyone can type. That limits it too Latin-1 (regardless of encoding)
Please, note that "everyone" cannot type Latin1 .
There are enough countries in the World, where the Latin1 symbols are not used at all. Moreover, they did not use ASCII in their culture initially. ASCII came later, as a "symbols for the technical English", because this language are used for computers for the historical reasons (as well as the French is used in diplomacy).
IMHO the issue here is a lack of geography knowledge. Some people ("kids" in terms of Ralf :) ) actually think that it is possible to travell from US to Europe on a car... (without the ferry :) ). Hence it is not too surprisingly that they think that all the people in the World use latin1 ...
You presume too much. This latter paragraph should not have been posted. Please stay on-topic.
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. 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. One could also add non-English comments to spec files and source code and justify it with the number of non-English Fedora contributors.
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. 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. (rpm itself BTW does not require the package name and the package filename to have any particular relationship).
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.
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.
I'm quite surprised people have such an English-centric view of an international project like Fedora.
2008/3/13 Nicolas Mailhot nicolas.mailhot@laposte.net:
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.
I'm quite surprised people have such an English-centric view of an international project like Fedora.
Languages are a tough nut to crack when it comes to collaboration. It's really difficult to get stuff done if a core group of people aren't able to communicate with each other using a common language. For most if not all of the technologies in this project, the tendancy happens to be English. This is reinforced by a lot of the historic choices made in to use ascii in the programming languages we are learn how to 'speak'. I'm sure there's an alternate universe out there where computer languages were originally based on Sanskrit. I might have even seen it on an episode of the Sliders tv show.
So as we try to expand the global project we are bound to find tension between the tendency for productive groups of people to need a common language, and the desire to see bring in a diverse group of people in the project in a substantial way. I'm not sure what the best answer here is. I will say that if the project was not English centric, I'd probably be unable to participate to much of any extent, so I'm sensitive to how non-English speakers feel about the situation. I'm hoping that having Max over in Europe helping to organize the much more language diverse community there, will bring some new ideas to the table.
-jef
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.
Hi.
On Fri, 14 Mar 2008 11:02:22 +0100, Michael Schwendt wrote
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.
And don't forget the fun you can have with different unicode code points that match to glyphs that look the same.
Α,Β and Ε are not the same as A, B and E (depending on your mail client/shell/whatever you use to display this these two blocks may look different, or they may not). The same goes for every tool that displays glyphs.
Le Ven 14 mars 2008 11:02, Michael Schwendt a écrit :
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.
Nope. You intentionally keep confusing the project name, the package name, the filename, commands, data, display, storage, technical artifacts, human communication, what is done Fedora-side with what is done upstream, etc.
The filename is not the package name. It's a technical artifact, plumbing.
The package name is not in the Fedora perimeter. The package name is a pointer to upstream. It's about the only bit of the package we have no say on with the License bit. Either we accept upstream choices or we don't package the result at all. (modulo minor tweaks such as capitalization, but none of the suggested transforms are minor tweaks).
We can decide comment rules, naming rules, versionning rules etc for stuff we produce ourselves. When we repackage other people's stuff we have to accept their core choices and there's little more core than how someone calls himself. You can regret them but that's about how far you can go. If you don't like them you can write your own solution yourself. That's basic ethics.
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.
It's up to the packagers to see if all the very real problems you point out are sufficient reason not to package something. Lack of translation is not a showstopper. Otherwise minefield would have been kicked out of rawhide. I can assure you an English-only UI in the main web browser is many orders of magnitude more user impacting than what all you rant on. (in other words, get a grip)
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.
This is Fedora-produced material. Our level of control on Fedora-produced material is higher than on upstream-produced material.
What would happen during package review with an application that is completely in German without any English message object files?
It would be accepted. Period. As long as there are Fedora users and a Fedora packager there is no reason to discriminate against German-speaking users for the sake of English-speaking users. We have many many apps which are not translated in all the languages Fedora spans.
If you can't understand an app you don't have to install it. Same rule for everyone. You question reeks of crass prejudice. What do you think langpacks and dictionnaries are? They're locale-specific Fedora components that can be totally uncomprehensible and useless to English-only speakers.
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.
The factual argument being?
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.
These are bugs to be fixed.
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?
No.
That's due to the fact Fedora is a *distribution*, built from *other* *entities* material, material that may be produced by non-English speakers at the destination of non-English speakers, using non-English languages, and it's totally *useless* to rant on the choices those entities should or should not have done since we benefit *hugely* from not having to do the work ourselves alone.
With your logic OpenOffice.org would have no place in Fedora. Fortunately others have been less dogmatic and admitted that valuable material does not have to be English only (even if pure English would have been more convenient).
The price of working with others is respect. Stomping on other people naming choices is utter disrespect. That's not how you build an healthy FLOSS community.
On Fri, 14 Mar 2008 15:55:08 +0100 (CET), Nicolas Mailhot wrote:
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.
Nope. You intentionally keep confusing the [...]
I disagree, and I see we don't discuss the same things. Perhaps you're on a mission.
I don't care about what names people give their software, whether they design shiny logos with glyphs that are unknown to me.
I don't care if they don't publish any web pages and documentation in a language I don't understand. If they don't want to be multi-lingual, that's not my problem.
I don't care whether there is a software package in the Fedora repository that uses only languages I don't understand, provided that it is not in a default install or otherwise tied into the system.
What I do care about is that the Linux distribution is not subverted with languages and glyphs I don't understand or can't display. I also very much care about the project language that is used on the primary mailing-lists, for example.
What would happen during package review with an application that is completely in German without any English message object files?
It would be accepted. Period. As long as [...]
Why did you continue after the "Period"? Is it so difficult to answer a question without adding presumptions? There is no reason to fight attempts at trying to understand the problems and the goal.
If you can't understand an app you don't have to install it.
Only if this is my decision actually. You say "an app", but realistically it could also be a library with a -devel package that finds its way into a dependency-chain (or even the buildroot) and contront users/packagers with no choice.
What do you think langpacks and dictionnaries are? They're locale-specific Fedora components that can be totally uncomprehensible and useless to English-only speakers.
Haven't you payed attention to my question about i17n/m17n/l10n?
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.
The factual argument being?
It's the reply to your "The ship has sailed long ago", and the argument is in the following sentence:
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.
These are bugs to be fixed.
So, the system is not ready yet, which is a blocker criterion as I pointed out before.
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?
No.
That's due to the fact Fedora is a *distribution*, built from [...]
When Star Division developed the closed-source Star Office, Fedora did not even exist.
With your logic OpenOffice.org would have no place in Fedora.
??? Now your confusion is complete. Please don't put words into my mouth. You don't know my "logic" yet.
Stomping on other people naming choices is utter disrespect. That's not how you build an healthy FLOSS community.
Ah, come on, this has nothing to do with disrespect. We already strip upstream tarballs and exclude certain stuff from it, because only parts of a product are compatible with our project policies. We disable features, we patch some things completely. Transliterating project names into characters from a limited package name alphabet is a matter of usability and technical concerns. The primary spins default to American English, with the translations only being secondary and as the translation project resources permit.
On Fri, 2008-03-14 at 17:05 +0100, Michael Schwendt wrote:
Ah, come on, this has nothing to do with disrespect. We already strip upstream tarballs and exclude certain stuff from it, because only parts of a product are compatible with our project policies. We disable features, we patch some things completely.
(The term for those things is "fork")
On Fri, 14 Mar 2008 12:17:48 -0400, Colin Walters wrote:
On Fri, 2008-03-14 at 17:05 +0100, Michael Schwendt wrote:
Ah, come on, this has nothing to do with disrespect. We already strip upstream tarballs and exclude certain stuff from it, because only parts of a product are compatible with our project policies. We disable features, we patch some things completely.
(The term for those things is "fork")
Technically, maybe, maybe not. Usually, real forks are not created at the package-level, but at the project level, i.e. they get a new upstream location and are actively developed [into a different direction than their original code base]. On the contrary, I don't think anyone really considers an upstream tarball, which is stripped off of mp3 codecs at the source-level or patched to use ABC instead of XYZ, a "fork". Still, it's an example of upstream products, which are not accepted in Fedora unmodified. If choosing a readable package name is considered as disrespectful, stripping and patching source tarballs is, too.
On Fri, 2008-03-14 at 19:57 +0100, Michael Schwendt wrote:
On the contrary, I don't think anyone really considers an upstream tarball, which is stripped off of mp3 codecs at the source-level
That one was fixed the way it should have been originally - upstream has accommodated us with a source level split (-good, -bad, -ugly).
If choosing a readable package name is considered as disrespectful, stripping and patching source tarballs is, too.
If you do it without at least trying to work with upstream on it, it definitely is.
Anyways, I just spoke up because recently I discovered Debian was patching some of my software - the patch was useful, but did I ever get a bug filed in the issue tracker or a post to the discussion group? Nope. Now I've been guilty of this myself before in the past, and in fact I maintained the GStreamer package years ago, and didn't do anything to try to work with upstream on the mp3 issue. Now I think people do talk too blithely about patching or modifying upstream as just part of "packaging"; there is a lot of responsibility to be taken with the power to patch.
Colin Walters (walters@redhat.com) said:
Anyways, I just spoke up because recently I discovered Debian was patching some of my software - the patch was useful, but did I ever get a bug filed in the issue tracker or a post to the discussion group? Nope. Now I've been guilty of this myself before in the past, and in fact I maintained the GStreamer package years ago, and didn't do anything to try to work with upstream on the mp3 issue. Now I think people do talk too blithely about patching or modifying upstream as just part of "packaging"; there is a lot of responsibility to be taken with the power to patch.
Waaaaaaaay back in the day (i.e., before Fedora) we asked the upstream of the first of these packages (XMMS) about it. They weren't interested in doing a release with it removed themselves.
Bill
On Fri, 2008-03-14 at 15:18 -0400, Bill Nottingham wrote:
Colin Walters (walters@redhat.com) said:
Anyways, I just spoke up because recently I discovered Debian was patching some of my software - the patch was useful, but did I ever get a bug filed in the issue tracker or a post to the discussion group? Nope. Now I've been guilty of this myself before in the past, and in fact I maintained the GStreamer package years ago, and didn't do anything to try to work with upstream on the mp3 issue. Now I think people do talk too blithely about patching or modifying upstream as just part of "packaging"; there is a lot of responsibility to be taken with the power to patch.
Waaaaaaaay back in the day (i.e., before Fedora) we asked the upstream of the first of these packages (XMMS) about it. They weren't interested in doing a release with it removed themselves.
Yeah, not every upstream is as good as Thomas is; on the other hand, few are worse than XMMS =)
On Fri, 14 Mar 2008 15:15:27 -0400, Colin Walters wrote:
On Fri, 2008-03-14 at 19:57 +0100, Michael Schwendt wrote:
On the contrary, I don't think anyone really considers an upstream tarball, which is stripped off of mp3 codecs at the source-level
That one was fixed the way it should have been originally - upstream has accommodated us with a source level split (-good, -bad, -ugly).
You seem to refer to GStreamer, whereas I refer to multiple other packages in general. We've had cases where upstream rejected patches (to implement dlopen plugins e.g.).
Anyways, I just spoke up because recently I discovered Debian was patching some of my software - the patch was useful, but did I ever get a bug filed in the issue tracker or a post to the discussion group? Nope.
In my experience (and it has been confirmed often) Debian is known for not submitting many patches and customisations upstream. And that is not limited to their self-written man pages.
Colin Walters wrote:
Now I think
people do talk too blithely about patching or modifying upstream as just part of "packaging"; there is a lot of responsibility to be taken with the power to patch.
Sure. That's one I reason I wrote
http://fedoraproject.org/wiki/PackageMaintainers/WhyUpstream
Rahul
Le Ven 14 mars 2008 17:05, Michael Schwendt a écrit :
On Fri, 14 Mar 2008 15:55:08 +0100 (CET), Nicolas Mailhot wrote:
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.
Nope. You intentionally keep confusing the [...]
I disagree, and I see we don't discuss the same things. Perhaps you're on a mission.
No more than you are.
I don't care about what names people give their software, whether they design shiny logos with glyphs that are unknown to me.
I don't care if they don't publish any web pages and documentation in a language I don't understand. If they don't want to be multi-lingual, that's not my problem.
I don't care whether there is a software package in the Fedora repository that uses only languages I don't understand, provided that it is not in a default install or otherwise tied into the system.
Very reasonable so far.
What I do care about is that the Linux distribution is not subverted with languages and glyphs I don't understand or can't display. I also very much care about the project language that is used on the primary mailing-lists, for example.
Here you take a massive leap into paranoïa land. Most what-if horror cases advanced in this thread already occurred, and the distribution was not subverted, the project primary language didn't change, in fact it was all so little invasive it wasn't noticed at all.
So I don't follow you. The evidence seems to be we cope with UTF-8 & non-English pretty well.
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.
These are bugs to be fixed.
So, the system is not ready yet, which is a blocker criterion as I pointed out before.
The system is never ready. This is IT. There are problems, they get fixed, and we don't wait for the perfect system before ack-ing a roadmap.
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?
No.
That's due to the fact Fedora is a *distribution*, built from [...]
When Star Division developed the closed-source Star Office, Fedora did not even exist.
So? We ship a lot of stuff developped before Fedora existed. And not only in historic packages. And I've not such an inflated view of Fedora to believe Fedora existing or not would have changed the slightest bit in the situation.
On Fri, 14 Mar 2008 17:58:30 +0100 (CET), Nicolas Mailhot wrote:
Nope. You intentionally keep confusing the [...]
I disagree, and I see we don't discuss the same things. Perhaps you're on a mission.
No more than you are.
Still I don't presume so much.
Very reasonable so far.
What I do care about is that the Linux distribution is not subverted with languages and glyphs I don't understand or can't display. I also very much care about the project language that is used on the primary mailing-lists, for example.
Here you take a massive leap into paranoïa land. Most what-if horror cases advanced in this thread already occurred, and the distribution was not subverted, the project primary language didn't change, in fact it was all so little invasive it wasn't noticed at all.
It's no secret that the review guidelines are incomplete/imperfect. Stuff can slip through until it is discovered.
So I don't follow you. The evidence seems to be we cope with UTF-8 & non-English pretty well.
Do you have more examples of UTF-8 package names in Fedora (without that I need to script a srpm/spec checker)?
So, the system is not ready yet, which is a blocker criterion as I pointed out before.
The system is never ready. This is IT. There are problems, they get fixed, and we don't wait for the perfect system before ack-ing a roadmap.
"Not ready yet" and "roadmap" are close to eachother. Let's imagine we didn't have UTF-8 filesystems already. That would be an example of "not ready yet" for UTF-8 package file names. Instead, we see that some multi-byte encoded file names display as "garbage" in default installations (text-mode as well as GUIs). That's the current case of "not ready yet" for permitting arbitrary package file names. Is that more comprehensible?
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?
No.
That's due to the fact Fedora is a *distribution*, built from [...]
When Star Division developed the closed-source Star Office, Fedora did not even exist.
So? We ship a lot of stuff developped before Fedora existed. And not only in historic packages. And I've not such an inflated view of Fedora to believe Fedora existing or not would have changed the slightest bit in the situation.
No further comment other than pointing out that OO.o's primary project website is in English. You argue and argue and argue, and I don't want to be dragged down that road.
Le vendredi 14 mars 2008 à 19:55 +0100, Michael Schwendt a écrit :
On Fri, 14 Mar 2008 17:58:30 +0100 (CET), Nicolas Mailhot wrote:
So? We ship a lot of stuff developped before Fedora existed. And not only in historic packages. And I've not such an inflated view of Fedora to believe Fedora existing or not would have changed the slightest bit in the situation.
No further comment other than pointing out that OO.o's primary project website is in English. You argue and argue and argue, and I don't want to be dragged down that road.
Unfortunately "don't want" sums up your argument pretty well.
On Fri, 14 Mar 2008 20:10:37 +0100, Nicolas Mailhot wrote:
Le vendredi 14 mars 2008 à 19:55 +0100, Michael Schwendt a écrit :
On Fri, 14 Mar 2008 17:58:30 +0100 (CET), Nicolas Mailhot wrote:
So? We ship a lot of stuff developped before Fedora existed. And not only in historic packages. And I've not such an inflated view of Fedora to believe Fedora existing or not would have changed the slightest bit in the situation.
No further comment other than pointing out that OO.o's primary project website is in English. You argue and argue and argue, and I don't want to be dragged down that road.
Unfortunately "don't want" sums up your argument pretty well.
With regard to German annotations in the ex-Star Office source code, yes.
On Fri, Mar 14, 2008 at 03:55:08PM +0100, Nicolas Mailhot wrote:
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.
This is Fedora-produced material. Our level of control on Fedora-produced material is higher than on upstream-produced material.
IMHO the Name tag in the spec file is also Fedora-produced material. Viewed as such, Fedora can and should mandate the format of the package name.
If full Unicode encoding in package names is accepted then: A non-English speaking user will still be presented with thousands of package names in Latin (us-ascii) encoding which are critical to the system with obscure names (kernel, glibc, glibc, firefox, etc.) These names are not understandable or even readable by the vast majority of earth's population. How is the experience of the non-English speaking user getting better by allowing one or two package names in their native tongue (Chinese, French, German)? The most likely feeling would be that the distribution is minimally translated, or that the localization was started but later abandoned.
If Fedora wishes to go down the road of full localization, then it should prepare itself for translation/transliteration of _all_ the package names in the distribution for each language. Anything else will just appear as a half baked approach to localization.
Thanks,
-- Sarantis
On Fri, Mar 14, 2008 at 11:02:22AM +0100, Michael Schwendt wrote:
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
The command line is unicode
What would happen during package review with an application that is completely in German without any English message object files?
Why should that be different to English or Chinese ?
# service ???????? start Starting ???????? services: [ OK ]
In xterm that name displays as white-space, in Emacs with interleaved white-space, in Sylpheed without white-space.
Diddums. We already use UTF-8 names in translations for the starting xxx service strings and it just works. Yes you need the fonts to match your locale but that has *NOTHING* to do with package naming.
Keeping English (AE and/or BE) as the project language helps against community fragmentation.
By excluding anyone who doesn't fit your little clique. You can totally avoid fragmentation by having one distro user only btw ..
On Sat, 15 Mar 2008 18:35:53 -0400, Alan Cox wrote:
The command line is unicode
But only few system command filenames need the multi-byte encoding.
What would happen during package review with an application that is completely in German without any English message object files?
Why should that be different to English or Chinese ?
What 'that'?
I asked the previous question, because we do have a policy that spec files and package descriptions must be in American English. Some reviewers would even criticise my British English spelling.
# service ???????? start Starting ???????? services: [ OK ]
Look, what your MUA did to the proper encoding! It was UTF-8, in your message it's "us-ascii" and killed them. ;)
In xterm that name displays as white-space, in Emacs with interleaved white-space, in Sylpheed without white-space.
Diddums. We already use UTF-8 names in translations for the starting xxx service strings and it just works. Yes you need the fonts to match your locale but that has *NOTHING* to do with package naming.
We don't translate package names, do we?
So, what do we do with non-English package names that require non-default fonts before they can be displayed?
Keeping English (AE and/or BE) as the project language helps against community fragmentation.
By excluding anyone who doesn't fit your little clique. You can totally avoid fragmentation by having one distro user only btw ..
In what language does Fedora EMEA report to the board? In what language do the various committees report to the board?
Let me emphasise that unlike you, I do not talk about "excluding" anyone.
"RC" == Ralf Corsepius rc040203@freenet.de writes:
RC> Unfortunately, my FPC colleagues seem to be keen on shooting RC> themselves into their foot and to be keen on letting Fedora's RC> usability to regress further.
Here I speak personally:
If you cannot accurately represent my position, which I made abundantly clear during the meeting, I respectfully requests that you make no public statements regarding it.
For the record: I abstained from the vote at the meeting because I believe it is inappropriate to consider the matter before we at least have sufficient information from the Infrastructure team as to whether it is even possible to support UTF8 package names. I made no statements as to my feet or to how I believe this will impact Fedora's usability.
- J<
Le Mer 12 mars 2008 12:29, Dmitry Butskoy a écrit :
Jason L Tibbitts III wrote:
- Ban unicode in package names (no draft submitted)
- Not accepted
Oops... The example of such an unicode name used is "écolier-fonts" .
Then consider any user in non-latin1 locale. For example, my locale is Russian. I have no "é" on my keyboard...
An ascii-only alias is provided in the spec file
On Wed, 2008-03-12 at 14:37 +0100, Nicolas Mailhot wrote:
Le Mer 12 mars 2008 12:29, Dmitry Butskoy a écrit :
Jason L Tibbitts III wrote:
- Ban unicode in package names (no draft submitted)
- Not accepted
Oops... The example of such an unicode name used is "écolier-fonts" .
Then consider any user in non-latin1 locale. For example, my locale is Russian. I have no "é" on my keyboard...
An ascii-only alias is provided in the spec file
This doesn't help users who are looking for the file:
=> This only helps those kids who are using one of these GUI-installers.
Nicolas Mailhot wrote:
Le Mer 12 mars 2008 12:29, Dmitry Butskoy a écrit :
Jason L Tibbitts III wrote:
- Ban unicode in package names (no draft submitted)
- Not accepted
Oops... The example of such an unicode name used is "écolier-fonts" .
Then consider any user in non-latin1 locale. For example, my locale is Russian. I have no "é" on my keyboard...
An ascii-only alias is provided in the spec file
You mean "Provides: foobar" ?
I mean I cannot operate with such a filename (with foreign sumbols) in my local copy of the Fedora repository. As well as a sysadmin of the primary Fedora sites cannot operate with such filenames, when people from "another World" (non Latin1 only) start to add their native-named packages into the common Fedora repo.
(Surely if you are not going to deprecate all non-latin language for this usage of unicode).
I prefer "Provides(de): foobar" etc., as for "Summary" or "%description". Maybe even:
Name: foobar Name(de): foobar Name(ru): фубар
but the RPM filename should be named by the primary "C locale" name.
IMO all ideas here should follow the spirit of gettext(3) (LANG, LC_MESSAGES, etc.etc.etc)
~buc
Dmitry Butskoy wrote:
Nicolas Mailhot wrote:
Le Mer 12 mars 2008 12:29, Dmitry Butskoy a écrit :
Jason L Tibbitts III wrote:
- Ban unicode in package names (no draft submitted)
- Not accepted
Oops... The example of such an unicode name used is "écolier-fonts" .
Then consider any user in non-latin1 locale. For example, my locale is Russian. I have no "é" on my keyboard...
An ascii-only alias is provided in the spec file
You mean "Provides: foobar" ?
I mean I cannot operate with such a filename (with foreign sumbols) in my local copy of the Fedora repository. As well as a sysadmin of the primary Fedora sites cannot operate with such filenames, when people from "another World" (non Latin1 only) start to add their native-named packages into the common Fedora repo.
(Surely if you are not going to deprecate all non-latin language for this usage of unicode).
You already have this problem because filenames within a package can legally be any unicode character.
I prefer "Provides(de): foobar" etc., as for "Summary" or "%description". Maybe even:
Name: foobar Name(de): foobar Name(ru): фубар
but the RPM filename should be named by the primary "C locale" name.
IMO all ideas here should follow the spirit of gettext(3) (LANG, LC_MESSAGES, etc.etc.etc)
This is a terrible idea.
A package name is a proper name. Localizing that in the spec file is like translating Ivan-John-Juan-Johann-Jean in a passport.
-Toshio
On Thu, 2008-03-13 at 01:00 -0500, Toshio Kuratomi wrote:
Dmitry Butskoy wrote:
Nicolas Mailhot wrote:
Le Mer 12 mars 2008 12:29, Dmitry Butskoy a écrit :
Jason L Tibbitts III wrote:
An ascii-only alias is provided in the spec file
You mean "Provides: foobar" ?
I mean I cannot operate with such a filename (with foreign sumbols) in my local copy of the Fedora repository. As well as a sysadmin of the primary Fedora sites cannot operate with such filenames, when people from "another World" (non Latin1 only) start to add their native-named packages into the common Fedora repo.
(Surely if you are not going to deprecate all non-latin language for this usage of unicode).
You already have this problem because filenames within a package can legally be any unicode character.
Yes, that's another leak in the FPG.
We should extend the FPG to ban all non unicode chars on all rpm-file-names, not only to package names (== %name).
I prefer "Provides(de): foobar" etc., as for "Summary" or "%description". Maybe even:
Name: foobar Name(de): foobar Name(ru): фубар
but the RPM filename should be named by the primary "C locale" name.
IMO all ideas here should follow the spirit of gettext(3) (LANG, LC_MESSAGES, etc.etc.etc)
This is a terrible idea.
ACK.
A package name is a proper name. Localizing that in the spec file is like translating Ivan-John-Juan-Johann-Jean in a passport.
ACK. The core of this issue is having _rpm-file-names_ which are constant and deterministic everywhere (Independent of the locale and tools being used).
Ralf
On Wed, 2008-03-12 at 14:29 +0300, Dmitry Butskoy wrote:
Then consider any user in non-latin1 locale. For example, my locale is Russian. I have no "é" on my keyboard...
Well, I can use cut and paste, when I have a mouse and the text is already shown on my desktop. But what I have to do, when use just the cmdline interface? IOW, without any GUI -- just the Linux console, or remote ssh session? How can I fill the "é" character then?
You use the compose key like most the world has been using for a long time.
System -> Preferences -> Hardware -> Keyboard -> Layout -> Layout Options -> Compose Key Position.
Personally I have it mapped to capslock, so that I can do <capslock> e ' which results in é
(setting aside the fact that compose key seems broken in rawhide...)
Jesse Keating wrote:
On Wed, 2008-03-12 at 14:29 +0300, Dmitry Butskoy wrote:
Then consider any user in non-latin1 locale. For example, my locale is Russian. I have no "é" on my keyboard...
Well, I can use cut and paste, when I have a mouse and the text is already shown on my desktop. But what I have to do, when use just the cmdline interface? IOW, without any GUI -- just the Linux console, or remote ssh session? How can I fill the "é" character then?
You use the compose key like most the world has been using for a long time.
System -> Preferences -> Hardware -> Keyboard -> Layout -> Layout Options -> Compose Key Position.
Personally I have it mapped to capslock, so that I can do <capslock> e ' which results in é
(setting aside the fact that compose key seems broken in rawhide...)
Support for the compose key seems pretty spotty. Yes, it worked fine in my [thunderbird] compose window [voilà], but not at all on the command line (using VT) or even in [x]emacs.
Is this supposed to be a set-once, use-always solution?
On Wed, 2008-03-12 at 10:42 -0400, Jesse Keating wrote:
On Wed, 2008-03-12 at 14:29 +0300, Dmitry Butskoy wrote:
Then consider any user in non-latin1 locale. For example, my locale is Russian. I have no "é" on my keyboard...
Well, I can use cut and paste, when I have a mouse and the text is already shown on my desktop. But what I have to do, when use just the cmdline interface? IOW, without any GUI -- just the Linux console, or remote ssh session? How can I fill the "é" character then?
You use the compose key like most the world has been using for a long time.
Another alternative (with different tradeoffs) is to use gucharmap. My workflow for entering Unicode characters is like this:
Alt-F2 gucha RET Ctrl-f e with RET (click on letter) Ctrl-c Alt-F4 Ctrl-v
It looks long, but really it's quite fast to type once you get used to it (the required click is a bug).
The advantages are that you don't need to know beforehand what the magic compose sequences are, and you can search for an arbitrary Unicode character, even ones with no corresponding compose sequence. The disadvantage is that it's slower than compose.
Jesse Keating wrote:
On Wed, 2008-03-12 at 14:29 +0300, Dmitry Butskoy wrote:
Then consider any user in non-latin1 locale. For example, my locale is Russian. I have no "é" on my keyboard...
Well, I can use cut and paste, when I have a mouse and the text is already shown on my desktop. But what I have to do, when use just the cmdline interface? IOW, without any GUI -- just the Linux console, or remote ssh session? How can I fill the "é" character then?
You use the compose key like most the world has been using for a long time.
System -> Preferences -> Hardware -> Keyboard -> Layout -> Layout Options -> Compose Key Position.
But I have no "Compose Key Position", as well as no "Layout Options", no "Layout", no "Keyboard", no "Hardware", no "Preference", and no "System". Guess why?
I am at the Linux console in a server room, and have no any GUI interface at all. Or I am in the ssh client throw my slow phone line, and am trying to operate on a file by some coreutils' utilities. And so one...
When some guys will add to Fedora some Japanese- Russian- Greek- etc. -named packages, what you have to do with them? Switch each time between some virtual keyboards? But if your server has no any GUI? Or you want to cause users always add pure GUI to ANY machine?
~buc
Dmitry Butskoy wrote:
Jesse Keating wrote:
On Wed, 2008-03-12 at 14:29 +0300, Dmitry Butskoy wrote:
Then consider any user in non-latin1 locale. For example, my locale is Russian. I have no "é" on my keyboard...
Well, I can use cut and paste, when I have a mouse and the text is already shown on my desktop. But what I have to do, when use just the cmdline interface? IOW, without any GUI -- just the Linux console, or remote ssh session? How can I fill the "é" character then?
You use the compose key like most the world has been using for a long time. System -> Preferences -> Hardware -> Keyboard -> Layout -> Layout Options -> Compose Key Position.
But I have no "Compose Key Position", as well as no "Layout Options", no "Layout", no "Keyboard", no "Hardware", no "Preference", and no "System". Guess why?
I am at the Linux console in a server room, and have no any GUI interface at all. Or I am in the ssh client throw my slow phone line, and am trying to operate on a file by some coreutils' utilities. And so one...
When some guys will add to Fedora some Japanese- Russian- Greek- etc. -named packages, what you have to do with them? Switch each time between some virtual keyboards? But if your server has no any GUI? Or you want to cause users always add pure GUI to ANY machine?
You may not like this answer (I don't know if I like it either) but I'm going to post it because it's important to know that you can operate on these filenames from the command line::
$ touch $'\303\261' $ ls ñ $ LANG=C ls -b \303\261 $ echo 'hi there' > $'\303\261' $ cat $'\303\261' hi there
-Toshio
Jesse Keating wrote:
On Wed, 2008-03-12 at 14:29 +0300, Dmitry Butskoy wrote:
Then consider any user in non-latin1 locale. For example, my locale is Russian. I have no "é" on my keyboard...
Well, I can use cut and paste, when I have a mouse and the text is already shown on my desktop. But what I have to do, when use just the cmdline interface? IOW, without any GUI -- just the Linux console, or remote ssh session? How can I fill the "é" character then?
You use the compose key like most the world has been using for a long time.
Yes. I actually use the compose key! But not for "é" ! Guess why? Because I use it for cyrillic (russian) input. And cyrillic (as well ass Japan, Hebrew etc.) has no "é" symbol.
~buc
On Wednesday 12 March 2008, Jason L Tibbitts III wrote:
- Ban unicode in package names (no draft submitted)
- Not accepted
According to the summary, there were two +1's, one -1 and one 0. Given the lack of quorum at the time and the slightly overall positive reaction to this, I think it's clear that this issue needs to be revisited later when there are enough people present.
And by the way, in my opinion the discussion should not be only about Unicode, but about restricting package names even to a subset of ASCII (let's say eg. a-z, A-Z, 0-9, -, +, _, .).
"VS" == Ville Skyttä ville.skytta@iki.fi writes:
VS> And by the way, in my opinion the discussion should not be only VS> about Unicode, but about restricting package names even to a VS> subset of ASCII (let's say eg. a-z, A-Z, 0-9, -, +, _, .).
This is why we need a concrete proposal to vote on. Things would have gone much better if we had one.
- J<
Jason L Tibbitts III wrote:
"VS" == Ville Skyttä ville.skytta@iki.fi writes:
VS> And by the way, in my opinion the discussion should not be only VS> about Unicode, but about restricting package names even to a VS> subset of ASCII (let's say eg. a-z, A-Z, 0-9, -, +, _, .).
This is why we need a concrete proposal to vote on. Things would have gone much better if we had one.
+1
One of the problems I have with "ban packages with unicode names" is that it doesn't consider what to do when a package name upstream is non-ASCii. My -1 vote is really a vote against having the Fedora packager make up a name for an upstream package which I very strongly oppose. If a proposal were written that told what the packager needs to do to get an acceptable package name I'd likely abstain or (possibly) agree.
-Toshio
On Thu, 2008-03-13 at 01:25 -0500, Toshio Kuratomi wrote:
Jason L Tibbitts III wrote:
> "VS" == Ville Skyttä ville.skytta@iki.fi writes:
VS> And by the way, in my opinion the discussion should not be only VS> about Unicode, but about restricting package names even to a VS> subset of ASCII (let's say eg. a-z, A-Z, 0-9, -, +, _, .).
This is why we need a concrete proposal to vote on. Things would have gone much better if we had one.
+1
One of the problems I have with "ban packages with unicode names" is that it doesn't consider what to do when a package name upstream is non-ASCii.
Transliterate/translate them to ASCII.
My -1 vote is really a vote against having the Fedora packager make up a name for an upstream package which I very strongly oppose.
Why would this be a problem?
May-be this is a problem with "pictographic" charsets (May-be traditional Chinese), but I am having difficulties to imagine this to be a problem elsewhere, because most (all?) languages have an nominal transliteration/translation to ASCII.
If a proposal were written that told what the packager needs to do to get an acceptable package name I'd likely abstain or (possibly) agree.
I agree that requesting such a name from upstream is advisable, but making it mandatory to me qualifies as bureaucracy.
Ralf
Ralf Corsepius wrote:
On Thu, 2008-03-13 at 01:25 -0500, Toshio Kuratomi wrote:
One of the problems I have with "ban packages with unicode names" is that it doesn't consider what to do when a package name upstream is non-ASCii.
Transliterate/translate them to ASCII.
This is a proposal I am strongly -1 to.
1) I am against doing this at the Fedora level because of the potential for different, non-obvious names to proliferate at the distro level to confuse end-users.
2) Translation and transliteration are two entirely different means of taking a word in one language into another and will yield two entirely separate ASCII strings. Leaving this ambiguous will exacerbate #1.
3) Collisions. Transliteration can cause collisions between different languages and homophones within a language. Translation is just as bad.
My -1 vote is really a vote against having the Fedora packager make up a name for an upstream package which I very strongly oppose.
Why would this be a problem?
May-be this is a problem with "pictographic" charsets (May-be traditional Chinese), but I am having difficulties to imagine this to be a problem elsewhere, because most (all?) languages have an nominal transliteration/translation to ASCII.
It is not as simple as you make out. With "pictographic" charsets (not only traditional Chinese) different languages may pronounce a character in different ways. So the transliteration will depend on the language the naming author was envisioning when they created it.
This isn't limited to pictographic languages. For instance, look at wikipedia's current rules on transliterating Cyrillic: http://en.wikipedia.org/wiki/Wikipedia:Naming_conventions_(Cyrillic)
Other things to note from wikipedia are that they have multiple methods of transliterating from cyrillic within a language depending on the usage of the word and whether it currently has a common transliteration. I think this is just too complex an issue for us to say there is one logical and right way to transliterate a name and expect every other distro to use the same conventions. This needs to be done cross-distro at least, upstream if possible.
-Toshio
On Thu, 2008-03-13 at 09:41 -0500, Toshio Kuratomi wrote:
Ralf Corsepius wrote:
On Thu, 2008-03-13 at 01:25 -0500, Toshio Kuratomi wrote:
One of the problems I have with "ban packages with unicode names" is that it doesn't consider what to do when a package name upstream is non-ASCii.
Transliterate/translate them to ASCII.
This is a proposal I am strongly -1 to.
IMO, you are making fuzz about nothing. For most languages such native transliterations exist.
My -1 vote is really a vote against having the Fedora packager make up a name for an upstream package which I very strongly oppose.
Why would this be a problem?
May-be this is a problem with "pictographic" charsets (May-be traditional Chinese), but I am having difficulties to imagine this to be a problem elsewhere, because most (all?) languages have an nominal transliteration/translation to ASCII.
It is not as simple as you make out. With "pictographic" charsets (not only traditional Chinese) different languages may pronounce a character in different ways.
That's why I mentioned them. It's a place I can imagine (I don't speak any Asian language nor can I write any of them), translation/transliteration could become problematic.
So the transliteration will depend on the language the naming author was envisioning when they created it.
Yes - But ask yourself: What is better, naming a package "koji" or seeing an (In my locale) unreadable Asian glyph (rsp. a "boxed char"), probably only Asians are able to type?
This isn't limited to pictographic languages. For instance, look at wikipedia's current rules on transliterating Cyrillic: http://en.wikipedia.org/wiki/Wikipedia:Naming_conventions_(Cyrillic)
Yes, transliteration into latin/ASCII depends on the authors locale!
Sometimes it's simple (as with French accents: "é->e"), sometimes it's less simple (as with German umlauts: ß->ss, ä->ae), sometimes it's more complicated (as with Cyrillic, Hebrew, Arab, etc.), sometimes it's difficult (e.g. Asian).
Other things to note from wikipedia are that they have multiple methods of transliterating from cyrillic within a language depending on the usage of the word and whether it currently has a common transliteration. I think this is just too complex an issue for us to say there is one logical and right way to transliterate a name and expect every other distro to use the same conventions. This needs to be done cross-distro at least, upstream if possible.
I do not agree. We should not try to solve the world's problems. Instead we should (IMO can not avoid to) restrict ourselves to a smallest common denominator to keep Fedora going.
Dimitry will not be able to type my last name (contains an é), I won't be able to type your name in its Japanese writing nor Dimitry's in his native Cyrillic spelling.
This doesn't have any impact on our current lives, because transliterations/translations exist.
Ralf
Le jeudi 13 mars 2008 à 17:47 +0100, Ralf Corsepius a écrit :
On Thu, 2008-03-13 at 09:41 -0500, Toshio Kuratomi wrote:
Ralf Corsepius wrote:
On Thu, 2008-03-13 at 01:25 -0500, Toshio Kuratomi wrote:
One of the problems I have with "ban packages with unicode names" is that it doesn't consider what to do when a package name upstream is non-ASCii.
Transliterate/translate them to ASCII.
This is a proposal I am strongly -1 to.
IMO, you are making fuzz about nothing. For most languages such native transliterations exist.
IMHO you are woefully unaware of the fuzziness of a transliteration process. Transliterating is akin to showing a colour to people and asking them to write down its RVB value (without using a colour picker tool). Some people will guess close, very experienced people will guess mighty close, but there's no way the results will be accurate or consistent.
And that is without taking national sensitivities into account. You may not care people transliterate your name but that's not the case of everyone.
Hell, many English-speaking people object if you force them to use orthographic rules of other English-speaking zones, and that's not even converting to another language, in another alphabet, of Names (not random words), using rules defined by another (maybe unfriendly) country.
On Thu, 2008-03-13 at 18:47 +0100, Nicolas Mailhot wrote:
Le jeudi 13 mars 2008 à 17:47 +0100, Ralf Corsepius a écrit :
On Thu, 2008-03-13 at 09:41 -0500, Toshio Kuratomi wrote:
Ralf Corsepius wrote:
On Thu, 2008-03-13 at 01:25 -0500, Toshio Kuratomi wrote:
One of the problems I have with "ban packages with unicode names" is that it doesn't consider what to do when a package name upstream is non-ASCii.
Transliterate/translate them to ASCII.
This is a proposal I am strongly -1 to.
IMO, you are making fuzz about nothing. For most languages such native transliterations exist.
IMHO you are woefully unaware of the fuzziness of a transliteration process.
Manual transliteration?
And that is without taking national sensitivities into account. You may not care people transliterate your name but that's not the case of everyone.
I am well aware this is a special problem in France.
Le jeudi 13 mars 2008 à 19:08 +0100, Ralf Corsepius a écrit :
On Thu, 2008-03-13 at 18:47 +0100, Nicolas Mailhot wrote:
Le jeudi 13 mars 2008 à 17:47 +0100, Ralf Corsepius a écrit :
On Thu, 2008-03-13 at 09:41 -0500, Toshio Kuratomi wrote:
Ralf Corsepius wrote:
On Thu, 2008-03-13 at 01:25 -0500, Toshio Kuratomi wrote:
One of the problems I have with "ban packages with unicode names" is that it doesn't consider what to do when a package name upstream is non-ASCii.
Transliterate/translate them to ASCII.
This is a proposal I am strongly -1 to.
IMO, you are making fuzz about nothing. For most languages such native transliterations exist.
IMHO you are woefully unaware of the fuzziness of a transliteration process.
Manual transliteration?
There's no such thing as a standard automated transliteration, because 1. there are many transliteration standards (from script to script, language to language, political regime to political regime) 2. they usually depend on word pronunciation (which is not the same as word writing, even for so-called phonetic scripts)
Automated transliteration is about as safe as feeding a long multiclause contract to babelfish and betting your future income on the result. Natural language processing is hard. International natural language processing is harder. And that's without considering that Names are the quirk-est part of any language.
On Thu, 2008-03-13 at 19:22 +0100, Nicolas Mailhot wrote:
Le jeudi 13 mars 2008 à 19:08 +0100, Ralf Corsepius a écrit :
On Thu, 2008-03-13 at 18:47 +0100, Nicolas Mailhot wrote:
Le jeudi 13 mars 2008 à 17:47 +0100, Ralf Corsepius a écrit :
On Thu, 2008-03-13 at 09:41 -0500, Toshio Kuratomi wrote:
Ralf Corsepius wrote:
On Thu, 2008-03-13 at 01:25 -0500, Toshio Kuratomi wrote: > One of the problems I have with "ban packages with unicode names" is > that it doesn't consider what to do when a package name upstream is > non-ASCii. Transliterate/translate them to ASCII.
This is a proposal I am strongly -1 to.
IMO, you are making fuzz about nothing. For most languages such native transliterations exist.
IMHO you are woefully unaware of the fuzziness of a transliteration process.
Manual transliteration?
There's no such thing as a standard automated transliteration,
That's why I am talking about manual transliteration - I do not want to automated transliteration nor automated translation.
That's why I am talking about using ... Name: ecollier-fonts ... Source0: écollier-fonts
and (optionally) to add Provides: écollier-fonts = %version-%release
This * caters usability (ls e*, rpm -U ecollier*rpm, LC_COLLATE) * avoids forcing upstream to rename their tarball * avoids stepping on the feet of national sensitivities.
Ralf
Le jeudi 13 mars 2008 à 19:29 +0100, Ralf Corsepius a écrit :
On Thu, 2008-03-13 at 19:22 +0100, Nicolas Mailhot wrote:
Le jeudi 13 mars 2008 à 19:08 +0100, Ralf Corsepius a écrit :
On Thu, 2008-03-13 at 18:47 +0100, Nicolas Mailhot wrote:
Le jeudi 13 mars 2008 à 17:47 +0100, Ralf Corsepius a écrit :
On Thu, 2008-03-13 at 09:41 -0500, Toshio Kuratomi wrote:
Ralf Corsepius wrote: > On Thu, 2008-03-13 at 01:25 -0500, Toshio Kuratomi wrote: >> One of the problems I have with "ban packages with unicode names" is >> that it doesn't consider what to do when a package name upstream is >> non-ASCii. > Transliterate/translate them to ASCII. > This is a proposal I am strongly -1 to.
IMO, you are making fuzz about nothing. For most languages such native transliterations exist.
IMHO you are woefully unaware of the fuzziness of a transliteration process.
Manual transliteration?
There's no such thing as a standard automated transliteration,
That's why I am talking about manual transliteration - I do not want to automated transliteration nor automated translation.
That's why I am talking about using ... Name: ecollier-fonts
This one people do care about, that's the project name not a technical string.
Source0: écollier-fonts
This one no one care about, its a technical name
and (optionally) to add Provides: écollier-fonts = %version-%release
This is a technical alias. It would be fine as technical workaround, it's not a substitute to the primary name a project feels an affect to.
In other words you reversed priorities to fit your needs, but the reversing is not innocuous, and you will offend people.
At one time Suse felt it smart to use 8:3 package filenames to cater to DOS mirrors. You seem to follow the same logic.
On Thu, 2008-03-13 at 19:59 +0100, Nicolas Mailhot wrote:
Le jeudi 13 mars 2008 à 19:29 +0100, Ralf Corsepius a écrit :
On Thu, 2008-03-13 at 19:22 +0100, Nicolas Mailhot wrote:
Le jeudi 13 mars 2008 à 19:08 +0100, Ralf Corsepius a écrit :
On Thu, 2008-03-13 at 18:47 +0100, Nicolas Mailhot wrote:
Le jeudi 13 mars 2008 à 17:47 +0100, Ralf Corsepius a écrit :
On Thu, 2008-03-13 at 09:41 -0500, Toshio Kuratomi wrote: > Ralf Corsepius wrote: > > On Thu, 2008-03-13 at 01:25 -0500, Toshio Kuratomi wrote: > >> One of the problems I have with "ban packages with unicode names" is > >> that it doesn't consider what to do when a package name upstream is > >> non-ASCii. > > Transliterate/translate them to ASCII. > > > This is a proposal I am strongly -1 to.
IMO, you are making fuzz about nothing. For most languages such native transliterations exist.
IMHO you are woefully unaware of the fuzziness of a transliteration process.
Manual transliteration?
There's no such thing as a standard automated transliteration,
That's why I am talking about manual transliteration - I do not want to automated transliteration nor automated translation.
That's why I am talking about using ... Name: ecollier-fonts
This one people do care about, that's the project name not a technical string.
Wrong - This is the technical string, a package is identified by.
Fedora has the liberty and need to impose restrictions on it.
That said, renaming écollier-fonts to ecollier-fonts is not any different from requiring certain prefixes on certain packages (perl-xxx) or other arbitrary renaming conventions (xxx-devel) or disallow blanks and special characters ($<>[]()\n\r\b\t) from package names.
Source0: écollier-fonts
This one no one care about, its a technical name
Wrong again: This is a file on a remote server, whose name is out of Fedora's control.
and (optionally) to add Provides: écollier-fonts = %version-%release
This is a technical alias.
Yes.
It would be fine as technical workaround, it's not a substitute to the primary name a project feels an affect to.
Nope: It's a string provided as legacy to tools which can use it. It's only visible inside of rpm and to tools applying metadata.
In other words you reversed priorities to fit your needs, but the reversing is not innocuous, and you will offend people.
At one time Suse felt it smart to use 8:3 package filenames to cater to DOS mirrors.
Their decision was right at the time they did so.
You seem to follow the same logic.
I can't deny the feeling you haven't understood anything I said :/
2008/3/13 Nicolas Mailhot nicolas.mailhot@laposte.net:
And that is without taking national sensitivities into account. You may not care people transliterate your name but that's not the case of everyone.
Just for the record.... if someone needs to transliterate my name into a different character set, I would prefer it if it were translated to mean 'cat vomit' when possible. I'm prepared to send troops if negotiations are needed.
-jef"and by troops i mean gummy bears and peeps"spaleta
On Thu, 2008-03-13 at 10:30 -0800, Jeff Spaleta wrote:
2008/3/13 Nicolas Mailhot nicolas.mailhot@laposte.net:
And that is without taking national sensitivities into account. You may not care people transliterate your name but that's not the case of everyone.
Just for the record.... if someone needs to transliterate my name into a different character set, I would prefer it if it were translated to mean 'cat vomit' when possible. I'm prepared to send troops if negotiations are needed.
-jef"and by troops i mean gummy bears and peeps"spaleta
little sugary troops. By the hundreds.
mmmm
-sv
Ralf Corsepius wrote:
On Thu, 2008-03-13 at 09:41 -0500, Toshio Kuratomi wrote:
Ralf Corsepius wrote:
On Thu, 2008-03-13 at 01:25 -0500, Toshio Kuratomi wrote:
One of the problems I have with "ban packages with unicode names" is that it doesn't consider what to do when a package name upstream is non-ASCii.
Transliterate/translate them to ASCII.
This is a proposal I am strongly -1 to.
IMO, you are making fuzz about nothing. For most languages such native transliterations exist.
My -1 vote is really a vote against having the Fedora packager make up a name for an upstream package which I very strongly oppose.
Why would this be a problem?
May-be this is a problem with "pictographic" charsets (May-be traditional Chinese), but I am having difficulties to imagine this to be a problem elsewhere, because most (all?) languages have an nominal transliteration/translation to ASCII.
It is not as simple as you make out. With "pictographic" charsets (not only traditional Chinese) different languages may pronounce a character in different ways.
That's why I mentioned them. It's a place I can imagine (I don't speak any Asian language nor can I write any of them), translation/transliteration could become problematic.
So the transliteration will depend on the language the naming author was envisioning when they created it.
Yes - But ask yourself: What is better, naming a package "koji" or seeing an (In my locale) unreadable Asian glyph (rsp. a "boxed char"), probably only Asians are able to type?
This isn't limited to pictographic languages. For instance, look at wikipedia's current rules on transliterating Cyrillic: http://en.wikipedia.org/wiki/Wikipedia:Naming_conventions_(Cyrillic)
Yes, transliteration into latin/ASCII depends on the authors locale!
Sometimes it's simple (as with French accents: "é->e"), sometimes it's less simple (as with German umlauts: ß->ss, ä->ae), sometimes it's more complicated (as with Cyrillic, Hebrew, Arab, etc.), sometimes it's difficult (e.g. Asian).
Other things to note from wikipedia are that they have multiple methods of transliterating from cyrillic within a language depending on the usage of the word and whether it currently has a common transliteration. I think this is just too complex an issue for us to say there is one logical and right way to transliterate a name and expect every other distro to use the same conventions. This needs to be done cross-distro at least, upstream if possible.
I do not agree. We should not try to solve the world's problems. Instead we should (IMO can not avoid to) restrict ourselves to a smallest common denominator to keep Fedora going.
Dimitry will not be able to type my last name (contains an é), I won't be able to type your name in its Japanese writing nor Dimitry's in his native Cyrillic spelling.
This doesn't have any impact on our current lives, because transliterations/translations exist.
So propose banning the package until upstream changes the name, gives an official transliteration to ASCII, or a cross-distro group decides on a transliterated name for it (It was just mentioned to me that there's a new mailing list and project for cross-distro collaboration. It's early in its development so this may or may not develop into the kind of place where this kind of collaboration would take place[1]_).
My objection is not based on unicode==good; it's based on not wanting to do at the distro level something that should be done for all packagers in all distros.
.. _[1]: http://lists.freedesktop.org/mailman/listinfo/distributions
-Toshio
tor 2008-03-13 klockan 09:41 -0500 skrev Toshio Kuratomi:
Ralf Corsepius wrote:
Transliterate/translate them to ASCII.
This is a proposal I am strongly -1 to.
Ok, then allow the full Unicode range in Name:.
But a decision needs to be made. Should it be possible to do all command line system management with only knowledge of the basic latin character set? Or even: Should it be possible to do all command line system management with _no_ knowledge if the latin character set? (That would mean transliterating "yum" and "ls".)
Probably the answers are "yes" and "uhm, perhaps if someone figures out how".
Then the output of the command line tools (rpm -q, yum list, ls *.rpm etc.) needs to be such that everyone who can type the command can also manually copy the output from the screen to the keyboard. The command can of course show several names, at the same time or using different options.
So you still need to provide those ASCII names somehow. The only alternatives to transliteration I can see are serial numbers of some kind, lots of '\xxx' in strings or punycode (xn-collier-fonts-9gb).
/abo
Alexander Boström wrote:
tor 2008-03-13 klockan 09:41 -0500 skrev Toshio Kuratomi:
Ralf Corsepius wrote:
Transliterate/translate them to ASCII.
This is a proposal I am strongly -1 to.
Ok, then allow the full Unicode range in Name:.
But a decision needs to be made. Should it be possible to do all command line system management with only knowledge of the basic latin character set? Or even: Should it be possible to do all command line system management with _no_ knowledge if the latin character set? (That would mean transliterating "yum" and "ls".)
Probably the answers are "yes" and "uhm, perhaps if someone figures out how".
Then the output of the command line tools (rpm -q, yum list, ls *.rpm etc.) needs to be such that everyone who can type the command can also manually copy the output from the screen to the keyboard. The command can of course show several names, at the same time or using different options.
I keep reading what you are asking here but have yet to find an interpretation that I can think reasonable. So let me give you my thoughts and then maybe we can meet in the middle. The questions:
1) Should the default command-line system administration commands use filenames that are ASCII only?
2) Should we be able to transliterate or translate those commands so they can be invoked from the command line using non-ASCII scripts.
My answers are yes dependent on a sensible definition of "command-line system administration commands" and no.
For 2 (being easier), I consider a command line application like yum or ls to be named by their invocation on the commandline. To transliterate those is once again falling into the trap of transliterating a proper noun akin to my passport example (Should a passport transliterate Ivan-John-Johann-Juan-Jean).
For 1, system commands need to be usable to all of our users. Taking the lowest common denominator of ASCII makes sense. Note that this question is intentionally different than your question #1 in several ways:
1) This applies only to the command name, not to data files or other things on the system. /bin/ls should be ASCII but the filenames it displays should be able to span the range of unicode.
2) This is not for every command name but only for "system administration commands". Once you get to the level of a desktop user, there are valid uses for unicode. And invalid uses are likely to have alternatives (Hate typing that unicode string to invoke your bittorrent client? Choose a different client).
So you still need to provide those ASCII names somehow. The only alternatives to transliteration I can see are serial numbers of some kind, lots of '\xxx' in strings or punycode (xn-collier-fonts-9gb).
'\xxx' is what I would think is correct but we already have the capability to display this in our command line tools. Are you proposing that instead of naming something with a unicode name and letting our tools display the code points for that when we ask them that our filenames are all escape sequences and our tools decode those to unicode? That just seems backwards to me.
-Toshio
On Fri, 2008-03-14 at 07:42 -0500, Toshio Kuratomi wrote:
Alexander Boström wrote:
tor 2008-03-13 klockan 09:41 -0500 skrev Toshio Kuratomi:
Ralf Corsepius wrote:
Transliterate/translate them to ASCII.
This is a proposal I am strongly -1 to.
Ok, then allow the full Unicode range in Name:.
But a decision needs to be made. Should it be possible to do all command line system management with only knowledge of the basic latin character set? Or even: Should it be possible to do all command line system management with _no_ knowledge if the latin character set?
No
(That would
mean transliterating "yum" and "ls".)
Probably the answers are "yes" and "uhm, perhaps if someone figures out how".
Then the output of the command line tools (rpm -q, yum list, ls *.rpm etc.) needs to be such that everyone who can type the command can also manually copy the output from the screen to the keyboard. The command can of course show several names, at the same time or using different options.
I keep reading what you are asking here but have yet to find an interpretation that I can think reasonable. So let me give you my thoughts and then maybe we can meet in the middle. The questions:
- Should the default command-line system administration commands use
filenames that are ASCII only?
Depends on how you mean this question.
* If you mean that all "default command-line tools" shall be named in ASCII, then the answer is more or less:
http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_0...
... 3.230 Name In the shell command language, a word consisting solely of underscores, digits, and alphabetics from the portable character set. The first character of a name is not a digit.
Note: The Portable Character Set is defined in detail in Portable Character Set.
C.f.: http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap06.html#tag_0...
* If you are referring to "should all installation-tools" (rpm, yum, apt, etc.) be able to process utf-8 filenames, then my answer is: Implementation detail. Nothing blocks these tools from doing so.
* If you are referring to "should all *rpm's" use ASCII file names, then my answer is: Yes. All rpm-filenames must use ASCII file names (rsp. from POSIX-portable charset), because only these are guaranteed to work everywhere.
BTW: Also compare for Debian's policy on package names: http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Package
Ralf
On Thu, Mar 13, 2008 at 07:44:28AM +0100, Ralf Corsepius wrote:
One of the problems I have with "ban packages with unicode names" is that it doesn't consider what to do when a package name upstream is non-ASCii.
Transliterate/translate them to ASCII.
Bad idea unless done very carefully.
1. While its trivial to transliterate German there are many languages where a naiive[1] transliteration causes a complete change of word meaning.
2. In some cultural contexts transliteration of personal names (if they end up in package titles) is considered rude.
3. Transliteration of a trademarked package name should not be done without consulting legal or specifically obtaining permission.
I don't think #2 and #3 will bite us but be careful of #1 as you can totally confuse people if you get a transliteration wrong.
Alan [1] Yes that should be i-double-dot but I'm transliterating to ascii for you. Even English isn't supported by ASCII ;)
On Sat, 2008-03-15 at 18:11 -0400, Alan Cox wrote:
On Thu, Mar 13, 2008 at 07:44:28AM +0100, Ralf Corsepius wrote:
One of the problems I have with "ban packages with unicode names" is that it doesn't consider what to do when a package name upstream is non-ASCii.
Transliterate/translate them to ASCII.
Bad idea unless done very carefully.
Correct.
- While its trivial to transliterate German there are many languages
where a naiive[1] transliteration causes a complete change of word meaning.
What makes you think, German is different?
(Germ.) Bär -> naively (broken) transliterated: (Germ.) Bar (Engl.) bar. (Germ.) Bär -> (correctly) transliterate: (Germ.) Baer == (Engl.) bear
- In some cultural contexts transliteration of personal names (if they
end up in package titles) is considered rude.
I consider forcing users to learn to type Chinese, Thai, French (arbitrary examples) charsets just to be able to install a package to be utterly rude.
Ralf
Le dimanche 16 mars 2008 à 18:05 +0100, Ralf Corsepius a écrit :
- In some cultural contexts transliteration of personal names (if they
end up in package titles) is considered rude.
I consider forcing users to learn to type Chinese, Thai, French (arbitrary examples) charsets just to be able to install a package to be utterly rude.
When you say "Hi, Tom" to a Chinese because you can't bother learning to speak his real name you're being rude. That's the same for other names.
Hi.
On Sun, 16 Mar 2008 18:05:45 +0100, Ralf Corsepius wrote
What makes you think, German is different?
Well, German is quite simple to transliterate into us-ascii, there are just a handful of rules.
The other way around is slightly more difficult, because it's not unambiguous.
Other languages are not so clearly cut, or conflicting rulesets exist.
On Sun, Mar 16, 2008 at 06:05:45PM +0100, Ralf Corsepius wrote:
- In some cultural contexts transliteration of personal names (if they
end up in package titles) is considered rude.
I consider forcing users to learn to type Chinese, Thai, French (arbitrary examples) charsets just to be able to install a package to be utterly rude.
How about English fonts - why are those different ? You seem to have a very inconsistent attitude. As for typing that is a complete red herring. We have gui tools for a reason and pango is happy doing pointy-clicky things with other locales.
Alan
Alan Cox wrote, at 03/17/2008 10:01 PM +9:00:
On Sun, Mar 16, 2008 at 06:05:45PM +0100, Ralf Corsepius wrote:
- In some cultural contexts transliteration of personal names (if they
end up in package titles) is considered rude.
I consider forcing users to learn to type Chinese, Thai, French (arbitrary examples) charsets just to be able to install a package to be utterly rude.
How about English fonts - why are those different ? You seem to have a very inconsistent attitude. As for typing that is a complete red herring. We have gui tools for a reason and pango is happy doing pointy-clicky things with other locales.
Alan
You must think of CUI. On CUI even displaying Kanji characters on it (ctrl-alt-F1) is very hard. On Fedora AFAIK only two components can do this, jfbterm (maintained by me) and bogl-bterm. And I don't know the way to type Kanji on CUI although I am a Japanese... (of course I don't remember the UTF-8 code map. Even a 15-year-old child have to learn ~2000 Kanji characters).
Well, IMO making rpm have Kanji character is a disaster...
Regards, Mamoru
On Mon, Mar 17, 2008 at 10:14:50PM +0900, Mamoru Tasaka wrote:
gui tools for a reason and pango is happy doing pointy-clicky things with other locales.
Alan
You must think of CUI.
Pango - output not input. We don't need to be able to type them just click on them.
I do agree btw that Kanji in an RPM name would be quite difficult, and it would only be appropriate in very unusual cases (if any).
Alan
On Monday, 17 March 2008 at 14:21, Alan Cox wrote:
On Mon, Mar 17, 2008 at 10:14:50PM +0900, Mamoru Tasaka wrote:
gui tools for a reason and pango is happy doing pointy-clicky things with other locales.
Alan
You must think of CUI.
Pango - output not input. We don't need to be able to type them just click on them.
I disagree. Should we introduce non-ascii characters into package names, I want to be sure that it is possible to type them in a command line. While you may choose to ignore CLI users, don't assume that everyone shares your opinion.
I do agree btw that Kanji in an RPM name would be quite difficult, and it would only be appropriate in very unusual cases (if any).
Well, if you allow one non-ascii character (for example, é), you have to be prepared to go all the way, otherwise people will keep pointing at the former and saying "But you allowed THAT one!".
Regards, R.
PS. Not that I'm in favour of non-ascii characters in package names, but I'm playing devil's advocate here. :)
"Dominik 'Rathann' Mierzejewski" dominik@greysector.net writes:
I disagree. Should we introduce non-ascii characters into package names, I want to be sure that it is possible to type them in a command line. While you may choose to ignore CLI users, don't assume that everyone shares your opinion.
CLI users should already know how to deal with characters they can't type. It isn't that hard to use wildcards or copy-paste.
Well, if you allow one non-ascii character (for example, é), you have to be prepared to go all the way, otherwise people will keep pointing at the former and saying "But you allowed THAT one!".
They can say that all they want. The community doesn't have to accept their argument.
/Benny
On Tue, Mar 18, 2008 at 08:46:18PM +0100, Benny Amorsen wrote:
"Dominik 'Rathann' Mierzejewski" dominik@greysector.net writes:
I disagree. Should we introduce non-ascii characters into package names, I want to be sure that it is possible to type them in a command line. While you may choose to ignore CLI users, don't assume that everyone shares your opinion.
CLI users should already know how to deal with characters they can't type. It isn't that hard to use wildcards or copy-paste.
Certainly not. It is very annoying to have to deal with character one cannot type, especially in CLI.
-- Pat
On Tue, 2008-03-18 at 20:46 +0100, Benny Amorsen wrote:
"Dominik 'Rathann' Mierzejewski" dominik@greysector.net writes:
I disagree. Should we introduce non-ascii characters into package names, I want to be sure that it is possible to type them in a command line. While you may choose to ignore CLI users, don't assume that everyone shares your opinion.
CLI users should already know how to deal with characters they can't type. It isn't that hard to use wildcards or copy-paste.
On the local machine, you can also use a CLI that uses a modern graphics toolkit and thus supports the input system:
On Tue, Mar 18, 2008 at 05:08:30PM -0400, Chris Ricker wrote:
On Tue, 18 Mar 2008, Colin Walters wrote:
On the local machine, you can also use a CLI that uses a modern graphics toolkit and thus supports the input system:
When that runs without X, I might listen
Even worse, I dont care how sophisticated the input system, I would personally find it quite impossible to enter the Japanese character for 'koji', or any other meaningful chinese/japanese/arabic/hebrew characters. -- Michael
Michael E Brown wrote:
On Tue, Mar 18, 2008 at 05:08:30PM -0400, Chris Ricker wrote:
On Tue, 18 Mar 2008, Colin Walters wrote:
On the local machine, you can also use a CLI that uses a modern graphics toolkit and thus supports the input system:
When that runs without X, I might listen
Even worse, I dont care how sophisticated the input system, I would personally find it quite impossible to enter the Japanese character for 'koji', or any other meaningful chinese/japanese/arabic/hebrew characters.
But what do you do when a package is written that uses the Japanese character for koji? You can't transliterate it to romaji because "koji" is already taken.
Upstream, upstream, upstream.
-Toshio
On Tue, Mar 18, 2008 at 04:25:55PM -0500, Michael E Brown wrote:
On Tue, Mar 18, 2008 at 05:08:30PM -0400, Chris Ricker wrote:
On Tue, 18 Mar 2008, Colin Walters wrote:
On the local machine, you can also use a CLI that uses a modern graphics toolkit and thus supports the input system:
When that runs without X, I might listen
Even worse, I dont care how sophisticated the input system, I would personally find it quite impossible to enter the Japanese character for 'koji', or any other meaningful chinese/japanese/arabic/hebrew characters.
The wierd thing is that to do this you'd type 'k-o-j-i' followed by hitting the space key a few times until the right character came up.
In other words, this is the same just using the ascii name but (a) takes longer and (b) not as accessible (in many senses of that word).
Rich.
Colin Walters wrote:
On Tue, 2008-03-18 at 20:46 +0100, Benny Amorsen wrote:
"Dominik 'Rathann' Mierzejewski" dominik@greysector.net writes:
I disagree. Should we introduce non-ascii characters into package names, I want to be sure that it is possible to type them in a command line. While you may choose to ignore CLI users, don't assume that everyone shares your opinion.
CLI users should already know how to deal with characters they can't type. It isn't that hard to use wildcards or copy-paste.
On the local machine, you can also use a CLI that uses a modern graphics toolkit and thus supports the input system:
Please, type Ctrl-Alt-F1 . Then login and work a little. Perhaps it will help to understand better...
On Wed, 2008-03-19 at 15:28 +0300, Dmitry Butskoy wrote:
Please, type Ctrl-Alt-F1 . Then login and work a little. Perhaps it will help to understand better...
I just tried it. It seems pretty primitive! Where are the tabs? How do I search the command output? I can't right click on processes to kill them? How come it doesn't have an nice history browser? I seem to have to wait after every command I run unless I add some weird '&' character?
... =)
Colin Walters wrote:
On Wed, 2008-03-19 at 15:28 +0300, Dmitry Butskoy wrote:
Please, type Ctrl-Alt-F1 . Then login and work a little. Perhaps it will help to understand better...
I just tried it. It seems pretty primitive! Where are the tabs? How do I search the command output? I can't right click on processes to kill them? How come it doesn't have an nice history browser? I seem to have to wait after every command I run unless I add some weird '&' character?
Probably you will find me as an idiot, but I actually use the Linux console in my professional life.
Sure, I use Internet, Mail, Office etc. using Gnome Desktop. But for some tasks it is more convenient for me to use TUI (vi, mc, even lynx) instead of GUI. Perhaps because I started at 1992 when good GUI was yet not present...
Actually, I cannot forget TUI/CLI anyway. I still work sometimes by slow phone lines (ppp), by a mobile communicator, or at the dumb terminal connected to com port of a server. Sometimes I have a graphical monitor, but it is too old to see good GUI on it. Etc...
Besides that, I prefer to know that anything what I do manually, I can script in a shell. What about GUI?..
~buc
On Wed, 2008-03-19 at 18:42 +0300, Dmitry Butskoy wrote:
Sure, I use Internet, Mail, Office etc. using Gnome Desktop. But for some tasks it is more convenient for me to use TUI (vi, mc, even lynx) instead of GUI. Perhaps because I started at 1992 when good GUI was yet not present...
Actually, I cannot forget TUI/CLI anyway. I still work sometimes by slow phone lines (ppp), by a mobile communicator, or at the dumb terminal connected to com port of a server. Sometimes I have a graphical monitor, but it is too old to see good GUI on it. Etc...
Besides that, I prefer to know that anything what I do manually, I can script in a shell. What about GUI?..
GUI doesn't mean !shell. gnome-terminal for example, it's a terminal emulator, you get a CLI. You can full screen it too so it's "like" a VT, but you gain all the extra fun of showing the gliphs correctly and being able to use things like a char map or the compose key.
Jesse Keating wrote:
GUI doesn't mean !shell. gnome-terminal for example, it's a terminal emulator, you get a CLI. You can full screen it too so it's "like" a VT, but you gain all the extra fun of showing the gliphs correctly and being able to use things like a char map or the compose key.
Well, but I have the compose key working at Linux console too. Moreover, I tune both the desktop and the console to switch between keyboard languages similar way.
Hence I actually can work with unicode filenames on the Linux console, and actually I work with them! But they are MY NATIVE language names (or just ASCII names, or mixed). The same for gnome-terminal.
I am against the situation when I have to work with "non-ascii && non-my-language" unicode characters, independent whether I use Linux console or GUI terminal emulator.
~buc
On Wed, 2008-03-19 at 15:28 +0300, Dmitry Butskoy wrote:
Please, type Ctrl-Alt-F1 . Then login and work a little. Perhaps it will help to understand better...
Thats why I have a remote shell tool from a graphical laptop. Only time I would ever be local to the box is when I broke the network, and then I wouldn't be bothering with some font rpm in an odd local. I'd be fixing the network so that I could leave the cold data center and get back to my desk to do real work.
On Wed, Mar 19, 2008 at 10:32:39AM -0400, Jesse Keating wrote:
On Wed, 2008-03-19 at 15:28 +0300, Dmitry Butskoy wrote:
Please, type Ctrl-Alt-F1 . Then login and work a little. Perhaps it will help to understand better...
Thats why I have a remote shell tool from a graphical laptop. Only time I would ever be local to the box is when I broke the network, and then I wouldn't be bothering with some font rpm in an odd local. I'd be fixing the network so that I could leave the cold data center and get back to my desk to do real work.
And those who want to use the console don't use fedora?
-- Pat
Patrice Dumas wrote:
On Wed, Mar 19, 2008 at 10:32:39AM -0400, Jesse Keating wrote:
On Wed, 2008-03-19 at 15:28 +0300, Dmitry Butskoy wrote:
Please, type Ctrl-Alt-F1 . Then login and work a little. Perhaps it will help to understand better...
Thats why I have a remote shell tool from a graphical laptop. Only time I would ever be local to the box is when I broke the network, and then I wouldn't be bothering with some font rpm in an odd local. I'd be fixing the network so that I could leave the cold data center and get back to my desk to do real work.
And those who want to use the console don't use fedora?
While RedHat Certification Exam needs cmdline, vi/nedit/mutt etc., I hope all is OK :)
But there is a tendency. In 2003, the exam was "on console" only, in 2007 gnome-terminal "is recommended". (But who used console, finished first ;) )
On Wed, 2008-03-19 at 19:13 +0300, Dmitry Butskoy wrote:
While RedHat Certification Exam needs cmdline, vi/nedit/mutt etc., I hope all is OK :)
But there is a tendency. In 2003, the exam was "on console" only, in 2007 gnome-terminal "is recommended". (But who used console, finished first ;) )
The RHCE exam which I just completed allows you to use anything that is available as a package in RHEL5 to accomplish your tasks. The few seconds it takes to fire up gnome desktop vs logging in at the shell was eaten up quite quickly by being able to have a browser open to local documents, a few gnome-terminal tabs open for man pages, local machine file editing, remote shell for testing things back, graphical tools to accomplish tedious tasks, etc...
I was one of the first to finish and I used a graphical console for everything (except for repairing the boot loader but I didn't need to mess with UTF-8 package names to fix the boot loader)
Jesse Keating wrote:
I was one of the first to finish and I used a graphical console for everything
But you can start to configure services while the system is installed. Choose text installation, switch to the shell (Alt-F2) and configure what is alrready installed... (Not my own skill though).
~buc
On Wed, 2008-03-19 at 19:28 +0300, Dmitry Butskoy wrote:
But you can start to configure services while the system is installed. Choose text installation, switch to the shell (Alt-F2) and configure what is alrready installed... (Not my own skill though).
Again, the time to install the few extra packages is trivial. Minutes. And in the real world you don't get extra credit for finishing 10 minutes faster, you just have to do it /right/ and have it be an easy to maintain system after the fact. I don't care if /you/ know how the system works, what I care about is the guy I'm going to have to hire in a few years to maintain the thing will know how it works without playing hours and hours of discovery.
Jesse Keating wrote:
On Wed, 2008-03-19 at 19:28 +0300, Dmitry Butskoy wrote:
But you can start to configure services while the system is installed. Choose text installation, switch to the shell (Alt-F2) and configure what is alrready installed... (Not my own skill though).
Again, the time to install the few extra packages is trivial. Minutes. And in the real world you don't get extra credit for finishing 10 minutes faster,
Not agree. I am working in production 24x7 environment, where 10 minutes cost too much...
what I care about is the guy I'm going to have to hire in a few years to maintain the thing will know how it works without playing hours and hours of discovery.
For me, in our production environment, we do not need any "monkey sysadmins". We want to have employees which are capable of "playing hours and hours of discovery" when needed. Perhaps it will actually ever not be needed, but we prefer that they had such experience.
On Thu, 2008-03-20 at 15:03 +0300, Dmitry Butskoy wrote:
Not agree. I am working in production 24x7 environment, where 10 minutes cost too much...
In a production environment if you're only working on one thing at a time, you've lost. You can spend the extra 3 minutes a well designed kickstart system would take to place the x libraries and various graphical apps on the system during install to answer some mails or repair another problem all from your desk. Once the install is done you can then call up the tools remotely and easily accomplish your task while even working on other things at the same time.
what I care about is the guy I'm going to have to hire in a few years to maintain the thing will know how it works without playing hours and hours of discovery.
For me, in our production environment, we do not need any "monkey sysadmins". We want to have employees which are capable of "playing hours and hours of discovery" when needed. Perhaps it will actually ever not be needed, but we prefer that they had such experience.
Prefer yes, able to find reasonably priced people for that maybe someday need? Not so easy. I would prefer to design our infrastructure so that it's easy to navigate, easy to maintain, logical, and efficient. Then I can reduce head count over time and have an easier time finding replacements when needed.
Why make things harder than they should be? Just so that you can be l33t?
Once upon a time, Dmitry Butskoy buc@odusz.so-cdu.ru said:
Jesse Keating wrote:
Again, the time to install the few extra packages is trivial. Minutes. And in the real world you don't get extra credit for finishing 10 minutes faster,
Not agree. I am working in production 24x7 environment, where 10 minutes cost too much...
If it is a "production 24x7 environment", then you either build a new system and swap over or use kickstart to automatically build a pre-tested and pre-configured setup. If 10 minutes matter, you don't wait for someone to click and choose install options and then manually configure things.
Chris Adams wrote:
Once upon a time, Dmitry Butskoy buc@odusz.so-cdu.ru said:
Jesse Keating wrote:
Again, the time to install the few extra packages is trivial. Minutes. And in the real world you don't get extra credit for finishing 10 minutes faster,
Not agree. I am working in production 24x7 environment, where 10 minutes cost too much...
If it is a "production 24x7 environment", then you either build a new system and swap over or use kickstart to automatically build a pre-tested and pre-configured setup. If 10 minutes matter, you don't wait for someone to click and choose install options and then manually configure things.
Do not take me so literally. I did not say that the text-install is more fast for all. I meant that for "skilled enough CLI user" some things could be faster when he/she does not use GUI. In some (perhaps specific) production environments it matters...
~buc
Once upon a time, Jesse Keating jkeating@redhat.com said:
Thats why I have a remote shell tool from a graphical laptop. Only time I would ever be local to the box is when I broke the network, and then I wouldn't be bothering with some font rpm in an odd local. I'd be fixing the network so that I could leave the cold data center and get back to my desk to do real work.
If the non-ASCII-named packages are just fonts (and other locale- specific data), I don't see a big problem. The problem is if we get other packages that you might actually need to "bother with" from a console.
Chris Adams wrote:
Once upon a time, Jesse Keating jkeating@redhat.com said:
Thats why I have a remote shell tool from a graphical laptop. Only time I would ever be local to the box is when I broke the network, and then I wouldn't be bothering with some font rpm in an odd local. I'd be fixing the network so that I could leave the cold data center and get back to my desk to do real work.
If the non-ASCII-named packages are just fonts (and other locale- specific data), I don't see a big problem.
Consider a case when a user have created a local copy of the whole Fedora repo, and then starts to prepare it. You have to work with several different font sets...
non-ASCII-named packages, if applicable, must be placed in a separate repositories (probably non-ASCII-named too), and such repositories are placed and are useful for the appropriate language areas.
~buc
Once upon a time, Dmitry Butskoy buc@odusz.so-cdu.ru said:
Chris Adams wrote:
If the non-ASCII-named packages are just fonts (and other locale- specific data), I don't see a big problem.
Consider a case when a user have created a local copy of the whole Fedora repo, and then starts to prepare it. You have to work with several different font sets...
That's not a common use though (and certainly not an "emergency console access" case). Even then, what do you mean by "prepare"? I run a mirror (as well as a mirror at home), and I've built custom images, but I've never done anything that touched every package. If I really need to mess with them, I can use an appropriate tool.
On Tue, Mar 18, 2008 at 08:46:18PM +0100, Benny Amorsen wrote:
CLI users should already know how to deal with characters they can't type. It isn't that hard to use wildcards or copy-paste.
I can't use copy-paste on my Volker-Craig VC 4404!
http://www.classiccmp.org/dunfield/tty/index.htm
Rich.
Richard W.M. Jones wrote:
On Tue, Mar 18, 2008 at 08:46:18PM +0100, Benny Amorsen wrote:
CLI users should already know how to deal with characters they can't type. It isn't that hard to use wildcards or copy-paste.
I can't use copy-paste on my Volker-Craig VC 4404!
Looks sarcasmish a little...
Actually, there are servers without VGA card at all. Sometimes ago Linux began to support "serial console" (and even Grub supports it fine). For such servers, a vt220-compatible dumb terminals (normally) used as a console. (Certainly, these terminals are a little more modern than in the link above :) )
It is not a corner case -- at list in my country, it is used wide enough in production environments (where the hard console MUST be in the server room etc.)
Besides that, CLI is very useful in remote administration, i.e. via ssh. Having a rest on a beach, I can operatively correct issues at my site using my mobile communicator with ssh client. (Certainly I know CLI fine, since 1992 :) ). Consider now, whether such is possible in the GUI-only world?
~buc
On Wed, Mar 19, 2008 at 03:48:26PM +0300, Dmitry Butskoy wrote:
Richard W.M. Jones wrote:
I can't use copy-paste on my Volker-Craig VC 4404! http://www.classiccmp.org/dunfield/tty/index.htm
Looks sarcasmish a little...
Actually, there are servers without VGA card at all. Sometimes ago Linux began to support "serial console" (and even Grub supports it fine). For such servers, a vt220-compatible dumb terminals (normally) used as a console. (Certainly, these terminals are a little more modern than in the link above :) )
[...]
I fully agree. Serial console is a very important use case -- I just checked the serial console on a server that I admin and it didn't appear to be able to use pasted Japanese characters at all. For example, pasting in にほん results in:
;'c+cls 'c
appearing on the command line.
TERM is vt100 and the serial console is a Cyclades TS2000, if that makes a difference.
Rich.
PS. VC 4404 was the first dumb terminal I used, connected to a Convex 1 supercomputer running some derivative of BSD. Wish I still had that :-)
Once upon a time, Dmitry Butskoy buc@odusz.so-cdu.ru said:
Actually, there are servers without VGA card at all. Sometimes ago Linux began to support "serial console" (and even Grub supports it fine). For such servers, a vt220-compatible dumb terminals (normally) used as a console. (Certainly, these terminals are a little more modern than in the link above :) )
I use a DEC VT510 and a long serial cable to manage servers. For some, I use an IPMI serial console.
The problem with "use the compose key" is that most of us don't know how to type somebody else's characters (well, that and the fact that my IBM model M keyboard doesn't have a compose key).
"Richard W.M. Jones" rjones@redhat.com writes:
On Tue, Mar 18, 2008 at 08:46:18PM +0100, Benny Amorsen wrote:
CLI users should already know how to deal with characters they can't type. It isn't that hard to use wildcards or copy-paste.
I can't use copy-paste on my Volker-Craig VC 4404!
Then use wild cards. I made two suggestions for a reason. This stuff really isn't hard -- not even when you're on a weird serial terminal to a HP/UX box from the last millennium.
/Benny
On Mon, 2008-03-17 at 09:01 -0400, Alan Cox wrote:
On Sun, Mar 16, 2008 at 06:05:45PM +0100, Ralf Corsepius wrote:
- In some cultural contexts transliteration of personal names (if they
end up in package titles) is considered rude.
I consider forcing users to learn to type Chinese, Thai, French (arbitrary examples) charsets just to be able to install a package to be utterly rude.
How about English fonts - why are those different ?
We have system console fonts - These happen to be English fonts rsp. usable for English users.
You seem to have a very inconsistent attitude.
What is inconsistent about this?
I am talking about users being able to administrate Fedora
As for typing that is a complete red herring.
How is that a red herring?
Are you able to type/read/understand any languages on this planet?
We have gui tools for a reason
GUI tools are only applicable to when a GUI is installed.
I realize, as it already manifests elsewhere with other poorly designed apps in Fedora, pure console installations, minimal installs, GUI-less installations are not considered target scenarios for Fedora.
and pango is happy doing pointy-clicky things with other locales.
Only if I bloat my installation with these useless font packages I am not able to read nor type in any case.
Ralf
Le Mer 19 mars 2008 12:52, Ralf Corsepius a écrit :
and pango is happy doing pointy-clicky things with other locales.
Only if I bloat my installation with these useless font packages I am not able to read nor type in any case.
Thank you for confirming you're not in the target userbase of the package which naming you complain of.
Nicolas Mailhot wrote:
Le Mer 19 mars 2008 12:52, Ralf Corsepius a écrit :
and pango is happy doing pointy-clicky things with other locales.
Only if I bloat my installation with these useless font packages I am not able to read nor type in any case.
Thank you for confirming you're not in the target userbase of the package
Please, understand that the "target userbase" of Fedora is not Latin1-only end-users. As well as not Cyrillic-only, Japan-only etc.
Since Fedora is an international project, It mean that for the Fedora's COMMON repository you have to use us-ascii names only. If for some reason you want non-us-english name with unicode characters, then create a separate repository (aka livna, freshrpms etc.), and promote that repository in its target areas only (i.e. additional repo with specific packages for Russia, additional repo for Japan, etc.).
Don't mess up all the languages in the common repository. The target of such a mess is no-one.
On Wed, Mar 19, 2008 at 12:52:25PM +0100, Ralf Corsepius wrote:
and pango is happy doing pointy-clicky things with other locales.
Only if I bloat my installation with these useless font packages I am not able to read nor type in any case.
No doubt some non English speakers feel the same about English fonts
Alan
On Wed, Mar 19, 2008 at 10:06:25AM -0400, Alan Cox wrote:
On Wed, Mar 19, 2008 at 12:52:25PM +0100, Ralf Corsepius wrote:
and pango is happy doing pointy-clicky things with other locales.
Only if I bloat my installation with these useless font packages I am not able to read nor type in any case.
No doubt some non English speakers feel the same about English fonts
But they'll have to cope with these in any case because many packages names are likely to be in ascii 7 bit for years. So avoiding adding more to the set of package name characters is unlikely to hurt those non English speakers because they have to cope with english in any case while it can hurt those non-native speakers from an incompatible group (latin1 versus east-asian, for example).
-- Pat
Alan Cox wrote:
On Wed, Mar 19, 2008 at 12:52:25PM +0100, Ralf Corsepius wrote:
and pango is happy doing pointy-clicky things with other locales.
Only if I bloat my installation with these useless font packages I am not able to read nor type in any case.
No doubt some non English speakers feel the same about English fonts
Nope.
I am non-English.
I learned English as a language with "abcdefghijklmnopqrstuvwxyz" characters, which are the same as ascii -- at least for the "international" technical English.
Any not-end-user computer man -- a sysadmin, a programmer, an advanced user -- is aware of the technical English anyway. It is like a "computer esperanto" for him.
~buc
On 13.03.2008 07:25, Toshio Kuratomi wrote:
Jason L Tibbitts III wrote:
> "VS" == Ville Skyttä ville.skytta@iki.fi writes:
VS> And by the way, in my opinion the discussion should not be only VS> about Unicode, but about restricting package names even to a VS> subset of ASCII (let's say eg. a-z, A-Z, 0-9, -, +, _, .).
FWIW, +1
This is why we need a concrete proposal to vote on. Things would have gone much better if we had one.
+1 One of the problems I have with "ban packages with unicode names" is that it doesn't consider what to do when a package name upstream is non-ASCii.
Well, I see your point, but on the other hand: do we need to have details like those you outline in the guidelines? There is enough in there already and they are hard to read and understand.
Further: And does the FPC really need and want to solve details like this? Trying to sort those out is of course a respectable goal, but it's not yet a big problem afaics.
So maybe it really just as simple as saying "ban packages with unicode names". or, to be more precise, make it something like: "Package names are limited to 'a-z, A-Z, 0-9, -, +, _, .' If you have a package with a different problem come to fedora-packaging-list and discuss with us; once we solved it in a few packages we can write a page like 'Hints how to adjust package names if they contain non-ASCII characters'".
That's easier for everyone. And then the problem can be solved step by step over time by those that are effected together with the FPC members. The 'Hints how to adjust...' page for that of course could and should be separated from the guidelines and not protected by the ACLs for easy maintenance.
The reason why I write this mail is because I think we over optimize things and try to regulate to many details (in Fedora in general, not specific to the FPC). That's afaics a lot of work for the committees (which we need for more important things), feels like bureaucracy for the packagers and slows us down more and more as things get more complicated. And even worse, you can think hours how to solve problems and all their details, you'll miss one or two special cases often, so a "hits page" maintained by those that are effected is IMHO a way better place for details than the guidelines.
[...]
Just my 2 cent.
CU knurd
Thorsten Leemhuis wrote:
On 13.03.2008 07:25, Toshio Kuratomi wrote:
Jason L Tibbitts III wrote:
>> "VS" == Ville Skyttä ville.skytta@iki.fi writes:
VS> And by the way, in my opinion the discussion should not be only VS> about Unicode, but about restricting package names even to a VS> subset of ASCII (let's say eg. a-z, A-Z, 0-9, -, +, _, .).
FWIW, +1
This is why we need a concrete proposal to vote on. Things would have gone much better if we had one.
+1 One of the problems I have with "ban packages with unicode names" is that it doesn't consider what to do when a package name upstream is non-ASCii.
Well, I see your point, but on the other hand: do we need to have details like those you outline in the guidelines? There is enough in there already and they are hard to read and understand.
Further: And does the FPC really need and want to solve details like this? Trying to sort those out is of course a respectable goal, but it's not yet a big problem afaics.
So maybe it really just as simple as saying "ban packages with unicode names". or, to be more precise, make it something like: "Package names are limited to 'a-z, A-Z, 0-9, -, +, _, .' If you have a package with a different problem come to fedora-packaging-list and discuss with us; once we solved it in a few packages we can write a page like 'Hints how to adjust package names if they contain non-ASCII characters'".
That's easier for everyone. And then the problem can be solved step by step over time by those that are effected together with the FPC members. The 'Hints how to adjust...' page for that of course could and should be separated from the guidelines and not protected by the ACLs for easy maintenance.
The reason why I write this mail is because I think we over optimize things and try to regulate to many details (in Fedora in general, not specific to the FPC). That's afaics a lot of work for the committees (which we need for more important things), feels like bureaucracy for the packagers and slows us down more and more as things get more complicated. And even worse, you can think hours how to solve problems and all their details, you'll miss one or two special cases often, so a "hits page" maintained by those that are effected is IMHO a way better place for details than the guidelines.
+1
Regards,
Hans
On Thu, 2008-03-13 at 09:59 +0100, Thorsten Leemhuis wrote:
On 13.03.2008 07:25, Toshio Kuratomi wrote:
Jason L Tibbitts III wrote:
>> "VS" == Ville Skyttä ville.skytta@iki.fi writes:
VS> And by the way, in my opinion the discussion should not be only VS> about Unicode, but about restricting package names even to a VS> subset of ASCII (let's say eg. a-z, A-Z, 0-9, -, +, _, .).
FWIW, +1
This is why we need a concrete proposal to vote on. Things would have gone much better if we had one.
+1 One of the problems I have with "ban packages with unicode names" is that it doesn't consider what to do when a package name upstream is non-ASCii.
Well, I see your point, but on the other hand: do we need to have details like those you outline in the guidelines?
In this case: Yes.
Package names (And rpm-file-names) are a fundamental basis of packaging.
Further: And does the FPC really need and want to solve details like this?
In this case: Yes. This problem is such kind of fundamental that it has to be solved.
Trying to sort those out is of course a respectable goal, but it's not yet a big problem afaics.
Emphasize on NOT YET.
The more people who are not aware about charset/encoding etc. issues enter the scene, the more similar cases we will be facing.
It's only the fact such packages so far have not existed and the fact people are now challenging this leak inside of the FPG, which had caused this issue to pop up.
So maybe it really just as simple as saying "ban packages with unicode names". or, to be more precise, make it something like: "Package names are limited to 'a-z, A-Z, 0-9, -, +, _, .'
Exactly - It could be this kind of simple.
Actually, I had expected this kind of solution to be obvious and "natural" to everybody being involved, but ... apparently, I was wrong.
Ralf
Seems my wording was not completely clear and fool-proof, so I try to clarify:
On 13.03.2008 11:07, Ralf Corsepius wrote:
On Thu, 2008-03-13 at 09:59 +0100, Thorsten Leemhuis wrote:
On 13.03.2008 07:25, Toshio Kuratomi wrote:
Jason L Tibbitts III wrote:
>>> "VS" == Ville Skyttä ville.skytta@iki.fi writes:
VS> And by the way, in my opinion the discussion should not be only VS> about Unicode, but about restricting package names even to a VS> subset of ASCII (let's say eg. a-z, A-Z, 0-9, -, +, _, .).
FWIW, +1
This is why we need a concrete proposal to vote on. Things would have gone much better if we had one.
+1 One of the problems I have with "ban packages with unicode names" is that it doesn't consider what to do when a package name upstream is non-ASCii.
Well, I see your point, but on the other hand: do we need to have details like those you outline in the guidelines?
In this case: Yes. Package names (And rpm-file-names) are a fundamental basis of packaging.
Further: And does the FPC really need and want to solve details like this?
In this case: Yes. This problem is such kind of fundamental that it has to be solved.
When I said "details" in those two and other parts of my mail I referred to the "what to do when a package name upstream is non-ASCii" part in the post I replied to and not the "ban packages with unicode names" (to which I indirectly gave my +1 earlier in the mail). Sorry if that wasn't obvious.
[...]
CU knurd
Thorsten Leemhuis wrote:
On 13.03.2008 07:25, Toshio Kuratomi wrote:
Jason L Tibbitts III wrote:
>> "VS" == Ville Skyttä ville.skytta@iki.fi writes:
VS> And by the way, in my opinion the discussion should not be only VS> about Unicode, but about restricting package names even to a VS> subset of ASCII (let's say eg. a-z, A-Z, 0-9, -, +, _, .).
FWIW, +1
This is why we need a concrete proposal to vote on. Things would have gone much better if we had one.
+1 One of the problems I have with "ban packages with unicode names" is that it doesn't consider what to do when a package name upstream is non-ASCii.
Well, I see your point, but on the other hand: do we need to have details like those you outline in the guidelines? There is enough in there already and they are hard to read and understand.
Further: And does the FPC really need and want to solve details like this? Trying to sort those out is of course a respectable goal, but it's not yet a big problem afaics.
Actually, my issue is I do not want us trying to solve the details. I think package name is a piece of information that has to be decided at something broader than the distro level. So if upstream is going to use a non-ASCii package name and we're going to ban it on that basis and that's it period, then I am not a -1 (I might vote 0 if my vote made no difference otherwise.)
So maybe it really just as simple as saying "ban packages with unicode names". or, to be more precise, make it something like: "Package names are limited to 'a-z, A-Z, 0-9, -, +, _, .' If you have a package with a different problem come to fedora-packaging-list and discuss with us; once we solved it in a few packages we can write a page like 'Hints how to adjust package names if they contain non-ASCII characters'".
I am against anything that leaves the packager with the impression that they should change the package name on their own in this case. This needs to be done at least cross-distro, more hopefully upstream. I'll reply to one of Ralf's messages with an example.
-Toshio
On Thu, 2008-03-13 at 08:01 -0500, Toshio Kuratomi wrote:
Thorsten Leemhuis wrote:
On 13.03.2008 07:25, Toshio Kuratomi wrote:
So maybe it really just as simple as saying "ban packages with unicode names". or, to be more precise, make it something like: "Package names are limited to 'a-z, A-Z, 0-9, -, +, _, .' If you have a package with a different problem come to fedora-packaging-list and discuss with us; once we solved it in a few packages we can write a page like 'Hints how to adjust package names if they contain non-ASCII characters'".
I am against anything that leaves the packager with the impression that they should change the package name on their own in this case.
I sense a mis-understanding: I do not want upstreams to change their tarball-names nor to ban packages from Fedora because their upstream names are non-ascii.
I want to see the file names of rpms in Fedora to be restricted 7bit-ascii.
E.g. to mandate the rpms being built from écollier-fonts.tar.gz to be named "ecollier-fonts-*.rpm" and not "écollier-fonts-*.rpm"
Ralf
-
Alan Cox -
Alexander Boström -
Benny Amorsen -
Bill Nottingham -
Callum Lerwick -
Chris Adams -
Chris Ricker -
Colin Walters -
Development discussions related to Fedora -
Dmitry Butskoy -
Dominik 'Rathann' Mierzejewski -
Gary Thomas -
Hans de Goede -
Jason L Tibbitts III -
Jef Spaleta -
Jesse Keating -
José Abílio Matos -
Mamoru Tasaka -
Michael E Brown -
Michael Schwendt -
Nicolas Mailhot -
Patrice Dumas -
Rahul Sundaram -
Ralf Corsepius -
Ralf Ertzinger -
Richard W.M. Jones -
Sarantis Paskalis -
Seth Vidal -
Thorsten Leemhuis -
Toshio Kuratomi -
Ville Skyttä