X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org Message-ID: <47F7E1D1.804DF919@dessent.net> Date: Sat, 05 Apr 2008 13:32:17 -0700 From: Brian Dessent X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: Libtool 2.2.2 References: <47F6A816 DOT 2010208 AT alice DOT it> <47F73BA6 DOT 6000001 AT alice DOT it> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Reply-To: cygwin AT cygwin DOT com Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Angelo Graziosi wrote: > and if cygport depend on libtool1.5, how can the user who needs > libtool2.2 install it without uninstalling libtool1.5+cygport+...? They would have to manually override the warning of setup in order to install libtool2.2+cygport. > If one install libtool2.2 without removing anything, it overwrite > libtool1.5, and I think this is a little confusing. Yes, it's not great but it's the best we can do. Feel free to suggest something less confusing, subject to the following constraints: - Both libtools can't exist on a system at once - Setup cannot express a mutual exclusivity, nor can it cause any package to be deselected The only thing I can think of is to wrap both libtool packages in a postinstall wrapper (as is currently done with the gcc-mingw-* packages) that first checks if the other is installed before unpacking anything. Then it could choose to either uninstall the other package, or decline to install itself. This is messy in that a) "cygcheck -c" / "cygcheck -l" / "cygcheck -f" cease to work as expected for the package and b) it's a lot more work to maintain such a package. (a) could be worked around by rewriting the manifest so that after the postinstall is run it looks like a normal package. > Suppose that an hypotetical user have not yet installed cygport and > libtool* packages. Then this user install libtool2.2. Suppose now that > the user needs also cygport: installing it, automatically libtool1.5 is > chosen, overwriting libtool2.2! So the user thinks is using libtool2.2 > instead, since installing cygport, is using libtool1.5! In the short term it would probably make more sense to simply drop libtool from the cygport 'requires:' and instead document somewhere that you need one or the other installed. Cygport could potentially drop something in profile.d to do this check and alert the user if something's wrong, however I dislike the idea of penalizing every cygport user with yet another task at the start of every login shell. It could also be possible for a cygport postinstall to check for libtool and only if not found drop something in profile.d that displays a warning. Yet another option would be to fix setup to allow more complex dependencies to be expressed, but that's even more complicated as a) SHTDI and b) there's always going to be users not using the latest setup.exe even months/years after a new version is released. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/