This is the mail archive of the
mailing list for the Cygwin project.
[Proposal] Moving user mount information to HKLM
- From: Doru Carastan <ivbdcc at pacbell dot net>
- To: cygwin at cygwin dot com
- Date: Sun, 29 Sep 2002 12:51:26 -0700
- Subject: [Proposal] Moving user mount information to HKLM
This is in reply to Christopher Faylor's post
> I am trying to set the mind set here. As the person responsible for
> 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
> 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.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html