Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
X-Authentication-Warning: istanbul.mpce.mq.edu.au: ypisan set sender to ypisan AT comp DOT mq DOT edu DOT au using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID: <14871.8472.688241.620444@istanbul.mpce.mq.edu.au>
Date: Sun, 19 Nov 2000 11:38:48 +1100 (EST)
To: cygwin AT sources DOT redhat DOT com
Cc: Andre Bleau <andre DOT bleau AT courriel DOT polymtl DOT ca>
Subject: Minor updates should not break existing programs (Was Re: OpenGL packaging)
In-Reply-To: <4.3.2.7.0.20001117150440.00b12e48@courriel.polymtl.ca>
References: <4 DOT 3 DOT 2 DOT 7 DOT 0 DOT 20001117150440 DOT 00b12e48 AT courriel DOT polymtl DOT ca>
X-Mailer: VM 6.75 under Emacs 20.5.1
X-PGP: C03EE479 = CD F1 E6 D2 B0 8B 24 28  ED 20 06 DA ED CB FC B8
From: Yusuf Pisan <ypisan AT comp DOT mq DOT edu DOT au>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id TAA28239


In terms of consistency within the cygwin project, installing things
into /usr is the right choice, but I would like to raise a red flag
about how versioning is done.

Let me first set the context:

I am planning to use cygwin/openGL as one of the platforms in the
computer graphics course.  I had prepared some Makefiles for standard
openGL examples (redbook, samples, some glut demos etc) that were
going to be pressed on a CD and distributed to students.  With some
basic instructions, the students would 'make' the examples and extend
them.

Now, I expect some students will naturally want to update their cygwin
version.  If I run setup and there is a new version of
gcc/openGL/whatever I usually choose to update to make sure that I do
not bang my head against bugs that have already been fixed.  I expect
not to break my existing working programs when I do minor version
upgrades.

Updating from opengl-1.1.0-2 to opengl-1.1.0-3 is going to break
existing code. This has to be made obvious to the user, with a big
warning sign, before allowing the user to proceed with it.

If I updated gcc and half my programs stopped working I would get very
upset. Especially, if I updated some stuff, did not notice the damage
right away, and came back to find programs not working. 

I am not especially concerned about openGL.  In this case, I am aware
of the problem and can adapt to it, but in general:

	- If upgrading a package may cause existing programs to break
          (either due to directory change or due to features being
          deleted), this should be flagged in setup.exe and the user
          should advised to read a specific web page before upgrading.

	- If upgrading a package may cause existing programs to break,
          the version number should be significantly different than
          the previous version.  There is a *big* diference between
          opengl-1.1.0-2 and opengl-1.1.0-3.

	- Package dependencies (if any) should be made clear.  I think
          redhat/rpm model is quite a good one.


I think cygwin is a great project and I hope to contribute to it as a
developer at some point.

Yusuf


Andre Bleau writes on 17/November/2000:
 > Larry Hall <lhall AT rfk DOT com> wrote:
 > >Its wrong only in the context of setup.exe.  It's designed to handle
 > >installations into /usr, not /usr/local.  If the OpenGL package is to be
 > >installed by setup.exe, it must be package under /usr.  That's it.
 > 
 > Alright, I surrender. The next OpenGL package (1.1.0-3) will be as follow:
 > 
 > /usr/bin/glut32.dll
 > /usr/doc/opengl-1.1.0/README.txt
 > /usr/doc/opengl-1.1.0/glui_manual_v2_beta.pdf
 > /usr/doc/opengl-1.1.0/glut-3.spec.pdf
 > /usr/include/glui.h
 > /usr/include/GL/gl.h
 > /usr/include/GL/glu.h
 > /usr/include/GL/glut.h
 > /usr/lib/libglui.a
 > 
 > Would that please everybody ? If so, I'll send an update next week.
 > 
 > 
 > André Bleau, ing., analyste
 > bleau AT courriel DOT polymtl DOT ca
 > 
 > Département de génie électrique et         Electric Engineering and
 > de génie informatique                      Computer Engineering department
 > École Polytechnique de Montréal            Montreal Polytechnic School
 > 
 > 
 > --
 > Want to unsubscribe from this list?
 > Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com

-- 
 ,--_|\   Yusuf Pisan
/      \  http://www.comp.mq.edu.au/~ypisan/
\_,--._*  Department of Computing
      v   Macquarie University, Sydney Australia 2109

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com