From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10210120346.AA05699@clio.rice.edu>
Subject: Re: File UItils at Clio 2.04 Query
To: djgpp-workers AT delorie DOT com
Date: Fri, 11 Oct 2002 22:46:18 -0500 (CDT)
In-Reply-To: <3DA6B6C4.E462F5E1@yahoo.com> from "CBFalconer" at Oct 11, 2002 07:32:20 AM
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> > > What do people think I should put on clio with regards to the file
> > > utilities built with the CVS LIBC? Some example I can think of are:-
> > >     a) Put File Utils 4.0 up there
> > >     b) Put File Utils 4.1 with rm.exe from File Utils 4.0
> > >     c) Put File Utils 4.1 with rm.exe from Core Utils
> > >     d) None - get people to use the File Utils 4.1 from simtel -
> > > this is what happens with the latest update

> > I like option c). From my point of view both fileutils 4.0 and 4.1
> > built against CVS have had about the same amount of testing. So
> > there's not much to choose between 4.0 and 4.1. Since I'm no longer
> > supporting 4.0, I'd prefer [as much as possible of] 4.1 to be
> > available.

I don't know of anything broken in the Fileutils 4.0 - so I would
just distribute 4.0 until we swap over (option a).  It seems there
are problems with Fileutils 4.1 on other platforms too, based on
another message (based on current 2.03 libc).  If we are "supporting" 
4.1, that would indicate that someone is spending time to find and 
fix bugs there.

Is there something broken in 4.0 and fixed in 4.1 which we feel is 
so important that we want to deal with a broken 4.1 rm?

> but it seems to me that if an earlier version works and a later
> doesn't it should be possible to pinpoint the difference, and
> correct the source accordingly.  

This is correct, but no one has had time to debug/diagnose/fix.
Since Fileutils 4.1 is a dead end, replaced by CoreUtils, any
effort is interesting but somewhat a throwaway.  If it's a Fileutils
4.1 assumption that is too unixy, we would just ifdef it out
(more like 4.0).  If it turfs up a bug in the libc, that might
be interesting (but unlikely).  If it's a bug in 4.1, we replace
it anyway with coreutils.  Unless someone is really interested,
it seems we roll back to 4.0 and spend time on coreutils port?

> The above sounds as if you will
> end up with a package that cannot be recreated from the source. 
> That will lead to future confusion.

It certainly sounds that way, and against the spirit of GPL.