delorie.com/archives/browse.cgi | search |
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 |
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
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |