This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
Re: Restructuring gettext
- From: "Robert Collins" <robert dot collins at itdomain dot com dot au>
- To: "Charles Wilson" <cwilson at ece dot gatech dot edu>,<cygwin-apps at cygwin dot com>
- Date: Fri, 14 Dec 2001 09:15:53 +1100
- Subject: Re: Restructuring gettext
- References: <3C18EBA9.9030102@ece.gatech.edu>
----- Original Message -----
From: "Charles Wilson" <cwilson@ece.gatech.edu>
> However, this means that the new gettext dll is not backward
compatible
> with packages linked against the old dll So, I've split it up into
two
> packages, and provided a "compatibility' package:
Ouch. Do you know why it's not compatible? (i.e. is auto-import breaking
something?)
> We can expect people to update gettext -- without installing
libintl0 --
> and reporting a "bug" to the list. I don't know how to deal with
this,
> other than perhaps to add a (not real) dependence on libintl0 in
> gettext's setup.hint to force an install...
Why? If gettext needs libintl1, and sharutils et al need libintl0, then
anyone who updates will get libintl0 automatically if they have
sharutils et al installed.
gettext should only depend on libintl1 IMO.
> How should we handle this sort of thing in the future, when
setup.hints
> of OTHER packages need to be updated, but the one forcing the change
> (me, in this case) is not the maintainer of those other packages?
Just do it, and email the maintainers asap. There's no nice way to
syncronise this.
IMO we can take steps to reduce the occurence of this: IIRC every time
it has happened it's been a .dll splitout from the original package
issue.
Rob