Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-apps-owner AT cygwin DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT cygwin DOT com>
List-Help: <mailto:cygwin-apps-help AT cygwin DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To: mailing list cygwin-apps AT cygwin DOT com
Message-ID: <0b5501c184be$8639eb80$0200a8c0@lifelesswks>
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>
References: <3C18EBA9 DOT 9030102 AT ece DOT gatech DOT edu>
Subject: Re: Restructuring gettext
Date: Fri, 14 Dec 2001 09:15:53 +1100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-OriginalArrivalTime: 14 Dec 2001 16:43:50.0975 (UTC) FILETIME=[826A6CF0:01C184BE]

----- Original Message -----
From: "Charles Wilson" <cwilson AT ece DOT gatech DOT 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