Subject: Re: small comment about shl20b.zip From: Tim Van Holder To: djgpp-workers AT delorie DOT com Cc: Juan Manuel Guerrero , Prashant TR , Eli Zaretskii In-Reply-To: References: 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.