Mail Archives: cygwin/2000/11/18/22:08:20
On Sun, Nov 19, 2000 at 11:38:48AM +1100, Yusuf Pisan wrote:
>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.
We're really quite clear on how versioning is done. Apparently someone
is unclear on what constitutes a major change and what constitutes a
minor change, however.
>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.
How do you expect an upgrade to opengl-1.1.0-3 to cause massive damage,
exactly? Moving things to /usr/lib and /usr/include should not break
anything unless you are actually hard-coding paths into your Makefiles.
If you are doing this, then you have a problem.
Regardless, if you don't like the default directory arrangement used by
setup, change it! Move things around to your liking. You can even build
your own version of opengl-27.27.27-1.tar.gz using any directory layout
that you want. And, setup.exe will even install it.
>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.
Would you care to detail how this is going to break existing code? I'm
much more swayed by examples and concrete facts than bold assertions
by potentially clueless posters.
>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.
Give me a break. If you don't like what you've installed, you can back
it out easily with setup. Or, just revert to your backups.
If you are really that concerned about breakage then be proactive and
guard against it yourself.
>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.
Maybe. If we feel like it. Probably not, though.
Infuriating isn't it? Life is so unfair. You get this stuff given to
you for free and it's just not exactly right. It just shouldn't be
allowed.
> - 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.
Again, you'll have to provide the rationale for this.
> - Package dependencies (if any) should be made clear. I think
> redhat/rpm model is quite a good one.
For about the 10,000th time: The setup program is a work in progress and
it's "Red Hat". Two words. Someday, someone may donate dependency checking
to setup or augment setup to understand RPM formats. I don't see anyone
actively pursuing this path now, though.
>I think cygwin is a great project and I hope to contribute to it as a
>developer at some point.
Hmm. That would be interesting, I'm sure.
Just to reiterate: 1) Unless I'm really missing something, this is not a
major change. Moving things from /usr/local to /usr should not break
anything, and 2) If this does cause problems, then move things around to
your liking or use older versions until we straighten things out.
cgf
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com
- Raw text -