[Bug 261881] Review Request: écolier-court-fonts - Ãâ°colier court fonts

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: écolier-court-fonts - Écolier court fonts


https://bugzilla.redhat.com/show_bug.cgi?id=261881





------- Additional Comments From nicolas.mailhot at laposte.net  2008-02-15 12:19 EST -------
(In reply to comment #25)
> (In reply to comment #24)
> > (In reply to comment #22)
> > > OK, I realize we have leak in the FPG, people seem to be keen to exploit.
> > 
> Yes, I consider this package review/submission as a provocation, trying to
> challenge the FGP.
> 
> The FPC and rpm missed to specify the precise syntax of rpm.specs.

I'm sorry I have zip interest into going in rant mode. Please move hyperbolics
somewhere else. 

> > > IMHO, this package name should be rejected, because
> > > a) It technically means asking for trouble wrt. tools processing rpms/rpm-spec
> > > (rpmbuild, rpm, yum, apt, yumex, createrepo, db-formats etc.). 
> > > I am sure at least some of them are not able to process such names.
> > 
> > What's asking for trouble is continuing to ignore UTF-8 handling problems in
> > low-level rpm tools.
> My view is differently: It is a matter of specification/standardization of the 
> "rpm.spec - syntax".

As noted in one of the first comments this was politely discussed with Seith
Vidal among others so don't be so quick to condemn me for not following the
hypothetical rule you assume will be written down someday. Plus you know what
they say about retroactivity of the law.

> > All our software stack has been moving to UTF-8 for years,
> Yes, and? ... this doesn't mean exploing the technical possibilities is
> necessary useful. (Think about using non-7bit application names).
> 
> > > b) It is user unfriendly: You can't expect people to be able to type
"arbitrary
> > > exotic characters" on their keyboard.
> > 
> > This is not a problem.
> Well, an acute accent probably is not much of a problem for French folks, but
> ... would you think the same wrt. non ASCII-chars of other languages?

Please don't invent strawmen. It's up to projects to choose names that play well
with their intended audience, and you're not well placed to decide here without
knowing their aims or their users they would be better served by ascii-7 names.
We already have a lot of parts in Fedora which are totally useless to people
that do not read a specific scripts, and this is good (globalization has
limits), so pretending everything needs an ascii-7 transliterated name is
stretching things quite a bit.

> At least I would be facing the such issues, if packages names (or worse
> applicaition) were named in East European, Middle and Far East charsets.
> 
> I would not be able find them on my keyboard. I also would be likely not to be
> able in GUI tools because I would not have the fonts installed. 

And you would likely not have any use for them. Projects with a global reach do
not use names in East European, Middle and Far East scripts.

> > The GUI tools do not care, and the package provides an
> > ascii-7 name alias for CLI users.
> These aren't of help, when e.g. ftp'ing a package.

Manual ftp-ing of packages has not been our primary distribution method for
years, and anyway rpm does not care about the file name so limiting metadata
just for filenames is a red herring.

> The converse would be applicable: ASCII-file/package-name, utf-8-provides.

This falls against the choices pretty much every other app did. You don't expose
low-level ascii-limited strings to users and hide the correct utf-8 variant. And
package name is a very important user-exposed string.

Also you should realise this would win you little, as the problems if there are
likely lurk rpm db side and will be largely the same either way.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.