Date: Wed, 24 Jun 1998 17:44:43 +0300 (IDT) From: Eli Zaretskii To: "Salvador Eduardo Tropea (SET)" cc: Nate Eldredge , djgpp-workers AT delorie DOT com, DJ Delorie Subject: Re: DJGPP v2.01 malloc wasting 4Kb In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk 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.