Subject: Re: small comment about shl20b.zip
From: Tim Van Holder <tim DOT van DOT holder AT pandora DOT be>
To: djgpp-workers AT delorie DOT com
Cc: Juan Manuel Guerrero <ST001906 AT HRZ1 DOT HRZ DOT TU-Darmstadt DOT De>,
   Prashant TR
	 <tr AT yahoo-inc DOT com>, Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
In-Reply-To: <Pine.SUN.3.91.1011115143321.14688E-100000@is>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1011115143321 DOT 14688E-100000 AT is>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Evolution/0.99.0+cvs.2001.11.06.15.07 (Preview Release)
Date: 15 Nov 2001 15:39:58 +0100
Message-Id: <1005835217.14276.0.camel@bender.falconsoft.be>
Mime-Version: 1.0
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

On Thu, 2001-11-15 at 13:36, Eli Zaretskii wrote:
> 
> On Thu, 15 Nov 2001, Juan Manuel Guerrero wrote:
> 
> > 1) No DJGPP port, no matter if it supports or not NLS,
> >    should install a charset.alias file in lib.
> 
> I agree with the goal, but the question is: is that goal reasonably 
> reachable?  If not, we are asking package maintainers something they
> cannot easily provide.
> 
> The problem, as I recall it, is that "make install" installs that file.  

I doubt that.  Except perhaps if the included gettext is used instead of
the installed one.  If that is the case, it may be that the standard
behaviour of the intl dir should be different for DJGPP, in which case
maintainers will need to use the DJGPP gettextize to update
gettext-using packages.

Now, checking a tarball for sh-utils 2.0j straight off alpha.gnu.org, I
see no reference whatsoever to charset.alias in either configure or
intl/Makefile.in.
So perhaps a DJGPP gettextize _was_ run on it to update the included
gettext library to a DJGPP-compatible one.  This would suggest a bug in
our gettextize (and/or our intl/Makefile.in) that causes charset.alias
to be installed when it shouldn't.

> > 2) The only ports that will continuosly provide an up to date charset.alias file,
> >    and will install them in lib, are gettext and libiconv.
> 
> Perhaps gettext and libiconv should make this file read-only.  This way, 
> the users will at least see a warning (or would they?).

Not more so than they do now (except if they normally use WinZip with
the 'overwrite without prompting' option enabled).  Plus, once it's
read-only, future versions of gettext/libintl won't be able to update it
either.

Plus, programs don't necessarily require an installed gettext - that's
why they come with their own library.  So it's fairly natural for them
to also include the support files needed by gettext (assuming
charset.alias is a gettext support file and not a libiconv support file;
if it's the latter, it has no business being anywhere but in the
libiconv package).  What we _can_ do is simply to put a requirement in
the Developer's section of kb.texi that no DJGPP package should ever be
configured with --with-included-gettext, and should instead depend on
the DJGPP package of gettext/libiconv.  That should prevent any such
files from ever being installed.