Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-developers-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com
From: Chris Faylor <cgf AT cygnus DOT com>
Date: Mon, 22 May 2000 23:09:01 -0400
To: cygwin-developers AT sourceware DOT cygnus DOT com
Subject: Re: Next net release will be 1.1.3
Message-ID: <20000522230901.A15569@cygnus.com>
Reply-To: cygwin-developers AT sourceware DOT cygnus DOT com
Mail-Followup-To: cygwin-developers AT sourceware DOT cygnus DOT com
References: <20000522172249 DOT A10159 AT cygnus DOT com> <200005222150 DOT RAA31092 AT envy DOT delorie DOT com> <20000522191937 DOT B14279 AT cygnus DOT com> <200005222328 DOT TAA31855 AT envy DOT delorie DOT com> <20000522213648 DOT A15412 AT cygnus DOT com> <200005230150 DOT VAA00356 AT envy DOT delorie DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <200005230150.VAA00356@envy.delorie.com>; from dj@delorie.com on Mon, May 22, 2000 at 09:50:33PM -0400

On Mon, May 22, 2000 at 09:50:33PM -0400, DJ Delorie wrote:
>> I can easily envision a user responding that the version is "1.1.1"
>> when asked what the version number is above, especially if they know
>> that Cygwin's version numbers are "always" x.y.z.
>
>Other GNU packages (binutils, gcc) use a non-release version for
>snapshots.  We should too.  Snapshots could be x.y.z.s or
>"ss-YYYYMMDD".  I hate to think that people using snapshots aren't
>smart enough to recognize a different version number style.

The utsname field that contains the version number will not accommodate
another nine characters so 1.1.1.20000522 is not feasible.  I don't
like a numbering scheme where it isn't obvious if ss-20000522 is
newer than 1.1.0.

Also, the packages on alpha.gnu.org seem to use all sorts of different
version number schemes.  I only see a couple that include date.

gdb does seem to have a date stamp.  The version that I recently built
from a fresh sourceware cvs update says "gdb 20000204".  The .tar.gz
files are named by the snapshot date, of course.

It may be that 99% of the people using snapshots will understand that
they have to include a string of additional digits when reporting a
version number but I was trying to put the focus of understanding on the
people supporting the product rather than the people reporting problems.

>We really do need to keep track of the installed tarballs and the files
>(size/checksum) that came from that tarball, so we *know* what setup
>last installed.  Trying to compensate for a user corrupting an
>installation by special casing one of the installable files sounds like
>it's going to cause problems in the long run.  A solution that works
>for *all* tarballs is a better goal, and we need that anyway.

Sure.  Put version number strings in all of the .exe's that are
installed.  Then if tar file A wipes out an executable that was also in
tar file B we don't rely on external, erroneous data about tar file A to
make update decisions.  That's a foolproof if impractical solution.

In any event, the only case that really needs special casing is cygwin.
One reason that it needs it is that the cygwin-1.1.0 tar file was named
cygwin-20000301.tar.gz.

The other reason is that people download snapshots and, if things stop
working, start moving things around in attempts to get things working
again.

>All setup needs to know is that you're supposed to have version foo of
>package bar installed, but you really have version grill, so you must
>reinstall.  Setup shouldn't care about newer, older, or version
>comparisons.  The only tricky part is figuring out what the version
>you're supposed to have installed is, and I think some config file on
>the FTP sites (or wherever; I posted a query about that) is the right
>way to go, because we may need to regress to an older version if we
>discover instabilities.

OK.  The regression point is a good one.  The current version of setup
can't handle anything like this of course.  You're talking about control
from the download site which would be cool.

My goal for the current crude version of setup was to allow a user
to type "setup -u" to have all of the packages on his system updated
with "newer" versions.

Setup doesn't know about versions or dates.  It just knows about
normalized strings of alphanumeric characters following a "-" and prior
to a .tar.gz.  It sorts based on those.

>>No one is talking about tossing version numbers.  That's your
>>interpretation.
>
>I meant that the FTP sites would never have odd version numbers.
>People who don't know about the snapshots would see 1.1.4, then 1.1.6,
>and wonder what happened to 1.1.5.

I guess I don't see this as a big deal.  When I go to download something
I always look for the newest thing to download.  With our directory
layout the only thing a person will see currently is the newest version.
They would actually have to remember that the last version was 1.1.4
to wonder what happened to 1.1.5.

Basically, I'm trying to make this work well enough so that people can
screw up and still recover.  There is adequate evidence on the cygwin
mailing list that people can screw up their systems royally and be
totally confused, so arguments about what people "should know" don't
mean much to me.

I just want "setup -u cygwin" to do the right thing as much as possible.
I don't care as much about "setup -u bash" or "setup -u textutils", at
least for now although I think there are fewer problems with people
playing with bash.exe than with cygwin1.dll.

"Incrementing by two" is something that would work for cygwin now.  It
doesn't involve another special case in setup.exe and it doesn't require
that we trust that the user has set up everything perfectly on their
system.  I could be wrong but I think that the number of "What happened
to cygwin 1.1.5" messages in the mailing list would be much less than
the "I think I upgraded to the newest net release but I still have the
same problem" messages.

As usual, I didn't expect that this would be a controversial topic.

I think my next post to this mailing list will be on the subject
of puppies and kittens.  (Hint:  I like them.)

cgf