From: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
To: <haible AT ilog DOT fr>
Cc: <djgpp-workers AT delorie DOT com>
Subject: RE: DJGPP specific patch for libiconv-1.5.1
Date: Mon, 26 Feb 2001 19:16:57 +0100
Message-ID: <CAEGKOHJKAAFPKOCLHDIEEAKCBAA.tim.van.holder@pandora.be>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <15002.28215.961848.395747@honolulu.ilog.fr>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> > Why cannot the official package be restructured so that it already has
> > all those directories?
> 
> This is unacceptable. It is exactly what I mean with "unduly
> restrictions for the maintainer".
I'd like to note that section 5.4 of the GNU coding standards (node 'Names'
in the info version) indicates you should take the 8+3 restriction into
account. While it does not require it, this would be especially valid when
developing a package that is supposed to work on DOS/Windows. So I don't
see it as 'undue restrictions'.

Admittedly, there are particularly many "problem files" in libiconv, so
there would be some work involved - delaying such a major change until
version 1.7 would obviously be quite acceptable, though it would
also increase the number of people using the current naming scheme.

Also, regarding your comment about the ugliness of the names in the
doschk output: there is no requirement to use 8+3 names; they can be as
long as you want, as long as the first 8+3 chars are unique in each
directory.