[Fedora-packaging] Drafts for next Tuesday

Nicolas Mailhot nicolas.mailhot at laposte.net
Fri Mar 21 07:53:47 UTC 2008


Le vendredi 21 mars 2008 à 04:37 +0100, Ralf Corsepius a écrit :
> On Thu, 2008-03-20 at 18:07 -0500, Jason L Tibbitts III wrote:
> > >>>>> "RC" == Ralf Corsepius <rc040203 at freenet.de> writes:
> > 
> > RC> Fedora is once more about to make a (IMNSHO) faulty decision.
> > 
> > Wow, someone has a device to predict the future.
> We are talking about "here and now" - The damage to Fedora allowing
> utf-8 and chars like $`, etc. in package names does is immediate.

Well, you're one of those who raised a stink and now as a result we're
likely to get a badly written authoritative guideline that explicitely
allows practices much worse than the ones you were complained about (for
a package you had no interest in regardless of its naming). Me, I've
always been in favour of authorising full utf-8 as soon as our tools
were fixed, and let packagers use their best judgement.

But anyway some comments on the proposal:

> While Fedora is an international community, for consistency and
> usability, there needs to be a common character set for package
> naming.

Neat, however the distribution already has a common character set we
enforce everywhere else, that's UTF-8 (even default character set in
some package tools like comps files), and this rationalization could
apply just as well to UTF-8. Why is it that after weeks of flames we
proponents of writing this guideline can not come with a clear
rationale?

(note that the first version of the proposal was even worse and called
for translating package names in English ; I don't think stuff like
libcaca is in any English dictionnary)

> Specifically, all Fedora packages must be named using only the 94
> printable characters defined by ASCII. These characters are displayed
> here:

At least the author was careful enough to forbid non-printable
characters. But a screenshot is insufficient as definition — a cyrillic
A would fit right in.

> Fedora packagers are strongly suggested to avoid using
> non-AlphaNumeric characters from the printable ASCII character set
> whenever possible, but they are permitted.

Since there is no clear rationale in the spec it's difficult to judge if
this kind of clause helps achieving the actual aim. Nevertheless I'll
note that:
– space is a printable ASCII character and it's not being forbidden in
the guideline. Need I point out how completely irrational it is to worry
about what packagers might do if allowed UTF-8 and then bless space?
– & <> and friends are going to wreak much more havoc than allowing
UTF-8 and letting packagers use their good judgement to determine how
much UTF-8 is reasonable would ever had
– if the rationale was to be mirror, and FTP-safe (one of the arguments
advanced on the list) I'll note there are very common limited platforms,
and very common storage media, which are unable to handle casing safely,
so allowing mixed-case names is dangerous (and if the limited platform
is not justifying the guideline I don't see what does)

I'll state it again: 

1. If we write a restrictive guideline, at least select correct
restrictions.

2. If no one can be bothered writing correct clear restrictions, do not
burden packagers with half-baked ones.

3. If we want a permissive guideline, stating that
 a. package names are UTF-8 encoded like the rest of the distro, 
 b. that packagers should use their good judgement to determine how
much UTF-8 is reasonable, 
 c. that infra has the mandate to fix our unicode bugs 
 d. and that it can embargo anything outside the basic latin block till
it's done
… is just as fine and does not reek of prejudice like this version.

Regards,

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-packaging/attachments/20080321/b7a0a347/attachment.sig>


More information about the Fedora-packaging mailing list