Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Reply-To: Cygwin List <cygwin AT cygwin DOT com>
Message-Id: <6.0.1.1.0.20031213133653.03a1ab00@127.0.0.1>
X-Sender: 
Date: Sat, 13 Dec 2003 14:21:27 -0500
To: "Hannu E K Nevalainen" <garbage_collector AT telia DOT com>,
   "Cygwin List" <cygwin AT cygwin DOT com>
From: Larry Hall <cygwin-lh AT cygwin DOT com>
Subject: RE: Third-party products that include Cygwin
In-Reply-To: <NGBBLLIAMFLGJEOAJCCEOEPGDGAA.garbage_collector@telia.com>
References: <6 DOT 0 DOT 1 DOT 1 DOT 0 DOT 20031209161313 DOT 0393cd68 AT 127 DOT 0 DOT 0 DOT 1>
 <NGBBLLIAMFLGJEOAJCCEOEPGDGAA DOT garbage_collector AT telia DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 04:53 PM 12/12/2003, Hannu E K Nevalainen you wrote:
>> From: Larry Hall
>> Sent: Tuesday, December 09, 2003 10:19 PM
>
><SNIP - here and there>
>
>>David A Cobb:
>>> However, I'm
>>> wondering if we could make it easier? How about storing
>>> /HKLM/Cygnus Solutions/Cygwin/DLL_PATH="native:/path/to/cygwin1.dll and
>>>                          /HKLM/Cygnus
>>> Solutions/Cygwin/DLL_VERSION="1.2.3"
>>>
>>>And providing a simple C routine to return the critical information.
>>>I'm less sure about this piece -- most use things like
>>> InstallShield and I don't know how the scripting works there. Of
>>> course, if they simply looked at the mount point
>>> /HKLM/Cyg.../Cygwin/mounts_v2/bin, they could work it all out!!!
>
>> The prescribed approach is for third parties to not bundle cygwin1.dll
>> but instead point to cygwin.com and say "Install This First".
>
> Not good for users that are unfamiliar with cygwin, uninterested in cygwin
>itself or something else on that "line".


Sure.  But it gets the job done and is the "easy" one for the dependent
third party package.  It's up to the third party to decide if it's important
enough to their user base to provide something more automated.  Either way,
this approach is *far* more maintainable and less troublesome for the user
in the long run.



>>  An
>> alternative is a nice automated way in their installer to invoke the
>> Cygwin installer.
>
> Heh... that would IMO require setup.exe to be able to do batch runs. Not
>possible, unless changes has been done very recently.



I think both Chris, Rob, and others have pointed out gap in your setup 
knowledge here.  'Nuff said.



>>  If they do this, then there's no chance of having
>> more than 1 cygwin1.dll installed and no one needs to check for one.
>> Of course, doing the checking is not hard (FindFirstFile()/FindNextFile())
>> even if it's not necessary.
>
> I'm not keen of seeing this kinds of solutions being run on my computer as
>it is "low spec" to put it mildly.
>
>First of all; The "FindFirstFile()/FindNextFile()" thingie would probably
>run for ten minutes, or even more. I would be sitting there wondering what
>the heck was happening, and I would *not* be polite to the person who
>created this misnomer.
> Second; how is this "FindFirstFile()/FindNextFile()" thing supposed to
>handle the existense of more than one device? i.e:
>
>$ mount | grep -re '^.: .*'
>P: on /dev/dvd type system (binmode)
>Q: on /dev/zip type system (binmode)
>R: on /dev/dcdr type system (binmode)
>S: on /dev/dcds type system (binmode)
>T: on /dev/dcdt type system (binmode)
>U: on /dev/dcdu type system (binmode)
>c: on /cygdrive/c type system (binmode,noumount)
>d: on /cygdrive/d type system (binmode,noumount)
>e: on /cygdrive/e type system (binmode,noumount)
>f: on /cygdrive/f type system (binmode,noumount)
>g: on /cygdrive/g type system (binmode,noumount)
>h: on /cygdrive/h type system (binmode,noumount)
>i: on /cygdrive/i type system (binmode,noumount)
>w: on /cygdrive/w type system (binmode,noumount)
>
>is what I have available currently. Is that thing supposed to look through
>all of it? If I connect my Digicams there will be three more devices to scan
>through. What if it finds more than one cygwin1.dll, is it supposed to erase
>the second one then?
>
>Please, don't even mention this anymore, that's real bad programming IMO.
>Not very likely to end up in something viable.


Ah come on Hannu.  I clearly mentioned this as an *option* and merely to 
clarify that finding a particular file is supported by the O/S at an API level.  I'm sure anyone that implemented this approach would use these APIs to do it the right way and wouldn't adopt your assumed "low spec" way.  I 
don't understand why you are trolling for flames on this topic.


>There got to be better, future-safe, flexible and extendable aproaches to
>this. 


Right.  They were discussed and I told you the recommended approach.  It
solves the problem and works for others.  If it doesn't for you, then
implement the solution you like that is better than the prescribed one
and propose it.


>A good *attempt* at this was presented above IMO.


I can only assume that David wasn't aware of the previous discussions on
this topic and the recommended solution.  If not, I don't see the benefit
of providing third parties with yet another solution.  It won't make our 
job any easier and if they're not taking advantage of the recommended 
solution, I can't believe that providing an alternative changes the situation 
in any way.  You're arguing for a solution on the wrong end of the problem 
here IMO.  Education/evangelization of the recommended approach is what's 
necessary.  If you're interested in helping to ease the problem of third 
party installation clashes, I'd suggest thinking about what can be done to 
"get the word out".  That's my point.




--
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
838 Washington Street                   (508) 893-9889 - FAX
Holliston, MA 01746                     


--
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/