Date:	Wed, 24 Jun 1998 17:44:43 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	"Salvador Eduardo Tropea (SET)" <salvador AT inti DOT gov DOT ar>
cc:	Nate Eldredge <nate AT cartsys DOT com>, djgpp-workers AT delorie DOT com,
	DJ Delorie <dj AT delorie DOT com>
Subject:	Re: DJGPP v2.01 malloc wasting 4Kb
In-Reply-To:	<m0yoout-000S3tC@inti.gov.ar>
Message-ID:	<Pine.SUN.3.91.980624171810.24854A-100000@is>
MIME-Version:	1.0

On Wed, 24 Jun 1998, Salvador Eduardo Tropea (SET) wrote:

> Looks like:
> 
> 1) Nobody have enough time and motivations to put v2.02 in beta.

I think we all invest in v2.02 as much time and motivation as we possibly 
can.  I know I do.  If you can help make it happen faster, please do.  
Accusing us in insufficient motivation is one thing that won't help.

> 1) Change the version number of the alpha to v2.10 because:

Changing a version number doesn't change the contents.  It's just 
semantics.

> a) It adds new features and not only fixes bugs.

So did v2.01 after v2.0.

> b) We need intermediate versions because we can't know when v2.10 will be
> available.

DJ thinks intermediate versions make maintenance harder.  He is the 
maintainer, so he gets to decide on that.  The patched libc was created to 
fill the need in the meanwhile.

> c) We need a way to distinguish between v2.01 and the patched v2.01.

We already have that: the patched libc is available from a different 
place, so there's no problem to distinguish between them.  It's not that 
we need to make sure everybody uses exactly the same libc.  Most of those 
who download the patched version know what they are doing, and the rest 
uses the stock version.  I don't see where's the problem.

> That's very important, specially if Eli is linking the binaries (and Eli
> is the porter of most of v2gnu directory) with this library! The user must
> know it! If the user doesn't know it and tries to recompile the gnu tool
> from sources he will get a buggy release.

In those cases where patched functions are *required* to build the 
binary, this is explained in the README.  In some extreme cases, I even 
put the patched sources of library functions into the source 
distribution, so people could patch their libraries before rebuilding.

I also don't think this is a big deal, since most of the people don't 
rebuild from sources.  If they would, I'd rather stop distributing 
binaries, as that's a lot of work.

> I think the patched library must be in the distribution because:
> Suppose a magazine puts djgpp on CD and distributes it. Then suppose a user
> buys the magazine and he don't have access to iNet. Then situation is very
> bad: he have the sources of the tools but no way to creat a bug-free binary.

Nothing prevents that magazine from putting the patched libc on the CD.  
That's what I did for the FSF CD-ROM that should be release RSN.  For all 
practical purposes, the patched libc *is* the intermediate version.  If 
the only problem is to make it available from SimTel, I don't have 
anything against it.  DJ?

Also, please note that some important patches in v2.02 are for the tools 
(like djtar and redir).  I don't think these are less important than 
libc.  Your suggestion ignores those bug-fixes.

> I know Eli can include the patches in the sources (are you doing it Eli?)
> but I think that isn't the right way.

The only right way I know is to contribute to the effort of debugging and 
putting v2.02 out the door as fast as we can.  This means taking part of 
the job of improving the library upon yourself, if you feel that v2.02 is 
moving too slowly.

- Raw text -