Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm 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 Date: Sun, 29 Sep 2002 12:51:26 -0700 From: Doru Carastan Subject: [Proposal] Moving user mount information to HKLM To: cygwin AT cygwin DOT com Message-id: <000701c267f1$988ad5d0$4501a8c0@scrapbox> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal This is in reply to Christopher Faylor's post http://cygwin.com/ml/cygwin/2002-09/msg01430.html > I am trying to set the mind set here. As the person responsible for cygwin > development, that's how we are progressing. I totally agree and apreciate the openness. > Actually, it doesn't work all that well, even in this context. We have a > problem with this RIGHT NOW, in fact. Getting this working reliably is > a constant battle. It was actually quite broken for months. It's only > a little broken now. Obviously I missed some technical problems. I managed to create an rpm based setup environment for win32 and it worked without too much problems using the 1.3.4 version. I mean without interfering with an installed cygwin of a different version (1.37, 1.3.9, 1.3.12). Please be assured that I understand very well your position. I am in the same battle at work. > Because getting it working reliably is hard and having two versions of the > DLL on the system is a technical support nightmare. You obviously are not > reading the cygwin mailing list. Agreed. And I do read every message on the 'cygwin' mail list. I have been doing it for more than 2 years. I do not want you to think I am sombody who just complain and do not understand your work. Myself and others probably are in the position to write applications or port some open source tools on Cygwin and try to distribute them within the GNU licensing limits. In my case I am almost done with a way to use rpm on win32 and UNIX (Solaris, Linux, etc) as part of a crossplatform solution. And that is without using or interfering with a possible rpm installation on UNIX or an existing Cygwin on windoze. I got rpm 4.0.2 and I got an old cygwin 1.3.7 doing it. Now I hear that this doesn't work no more. If it is for a good reason than my bet was wrong. It happens all the time. This leaves me only one option. To install/upgrade Cygwin on the users computer. It is a hard task. Very hard one considering so many things that can go wrong. With this in mind I will like you to consider publishing in the Cygwin FAQ the guidlines one should use for distributing an (open source) application outside the official net release. I believe it is an important topic in the spirit of 'getting our minds set'. Personally I am thinking of using the setup tool to install the packages that creates the environment used to build the application and add the extra application package(s) to setup.ini. The user will be forced, but ultimately it will be his/her choice, to upgrade/downgrade to the version required by the application. It will also be my problem when a new Cygwin breaks the application. This will require me, as a vendor, to either distribute a new version every time a new Cygwin breaks the binary compatibility or have the user recompile the application that relies on Cygwin. I am sure you see this in a broader perspective. Thank you, Doru Carastan -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/