Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sources DOT redhat DOT com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14871.35179.43577.159463@istanbul.mpce.mq.edu.au>
Date: Sun, 19 Nov 2000 19:03:55 +1100 (EST)
To: cygwin AT cygwin DOT com
CC: Christopher Faylor <cgf AT redhat DOT com>
Subject: Re: Minor updates should not break existing programs (Was Re: OpenGL packaging)
In-Reply-To: <20001118220703.A9181@redhat.com>
References: <4 DOT 3 DOT 2 DOT 7 DOT 0 DOT 20001117150440 DOT 00b12e48 AT courriel DOT polymtl DOT ca>
	<14871 DOT 8472 DOT 688241 DOT 620444 AT istanbul DOT mpce DOT mq DOT edu DOT au>
	<20001118220703 DOT A9181 AT redhat DOT com>
From: Yusuf Pisan <ypisan AT comp DOT mq DOT edu DOT au>


Christopher Faylor writes on 18/November/2000:
 > 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.

I was expecting compiled programs to croak because they could not load
a dll or a library.  As it turns out, I was wrong (and will even admit
to it).  Moving things from /usr/local to /usr does not break things.
I jsut tested it.  In fact, Makefile's no longer have to look at
/usr/local which is even better.

As for hard-coding paths into Makefiles, yes I was explicitly
including /usr/local/include as one of the places to look for include
files as /usr/local was not originally listed.

 > 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.

Agreed. My post was on whether minor upgrades should be allowed to
break existing code, not on where a piece of code should 'ideally' go.

 > 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.

My apologies.  I thought dll loading would create a problem and it
does not.

 > 
 > >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.

Agreed and I think we both agree that for cygwin's success it is
important to make sure that minor updates do not break any existing
code.  As it is, updating opengl or other packages does not break
existing code so there is no problem.

 > >	- 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.

If the expressed attitude was actually the way things are done, cygwin
would annoy users very quickly and would loose its user base.  As it
is, minor updates do not break existing programs (despite my mistake
about opengl) and users are happy with cygwin.

 > 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.

Many a free project has died due to small problems.  I like cygwin, I
think it is a great effort, and I was puzzled by seeing an approval
for a change which I (mistakenly) thought would break existing code,
so I expressed my opinions.

I think this forum exists to get feedback from cygwin users.  I think
slamming users with 'you get it for free, deal with it' attitude is
not the intention. 

 > 
 > >	- 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.

For the final time, I will accept my mistake, so we can move on.
Moving stuff from /usr/local to /usr is not a *big* difference. 

 > >	- 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.

Agreed, and for all programs that are work in progress there is a
'wish list'.  I do not expect you or somebody else to implement a
feature as soon as it is mentioned on the mailing list, but having
these 'wishes' in the archive or on some TODO list is a good thing.

 > 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

Christopher, you are correct, change in opengl is not a major change.
I stand corrected.

Yusuf

-- 
 ,--_|\   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