Mail Archives: cygwin/2000/11/18/19:42:54
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
- Raw text -