Re: Ready for test coreutils-5.2.0-1 [again]

[Mark Blackburn <marklist at fangorn dot ca>]

Nicholas Wourms wrote:

[...]

> I have a suggestion for how to deal with the "old" 
> fileutils/textutils/etc.  Provide "empty" versions of the packages 
> this replaces, bumping each by 1 revision.  This way, it should 
> "uninstall" the old stuff before installing the new stuff.  At least, 
> it worked for Jan when the new teTeX packages were made.  Also, IIRC, 
> some of the packages were linked against libbinmode.a to prevent 
> problems with CR/LF.  I wonder if this ought to be libautomode?
Do I create the empty packages or is it up to the previous maintainers 
of fileutils/textutils/sh-utils to do this? And is it simply a matter of 
running:
 for i in fileutils-4.2-3.tar textutils-2.0.21-2 sh-utils-2.0.15-5; do
   touch  $i; bzip2 $i
 done

About linking with libbinmode.a (or as cgf noted binmode.o), I built 
fileutils, textutils and sh-utils from the cygwin src packages and I 
didn't see that being done.

> Also, our /bin/sh is pretty much braindead (no job control, amoungst 
> other things) since it was decided that shaving 50k off of ash is 
> worth not having a POSIX compliant version.  Subsequently, the nohup 
> script will not work with /bin/sh (ash), so it is necessary to force 
> it to use bash instead.  See the following scripts from mknetrel to 
> see what needs to be done pre/post config & build:
> http://sources.redhat.com/cgi-bin/cvsweb.cgi/mknetrel/extra/fileutils?rev=1.2&content-type=text/x-cvsweb-markup&cvsroot=cygwin-apps 
>
> http://sources.redhat.com/cgi-bin/cvsweb.cgi/mknetrel/extra/sh-utils?rev=1.3&content-type=text/x-cvsweb-markup&cvsroot=cygwin-apps 
>
> http://sources.redhat.com/cgi-bin/cvsweb.cgi/mknetrel/extra/textutils?rev=1.2&content-type=text/x-cvsweb-markup&cvsroot=cygwin-apps 
The nohup in coreutils is a binary, not a script as in sh-utils. So I 
don't know whether the mknetrel scripts have any relevance for coreutils.

> Note that it is easier to just to pass -L/usr/lib -lbinmode to LDFLAGS 
> instead of bothering with printing gcc's search path.
>
> Finally, this is kinda picky, but why not use bzip2 instead of gzip 
> for the manpages?

If in the future, man pages are to be bzipped instead of gzipped then 
maybe a patch should be made to generic-build-script. AFAIK no cygwin 
package currently bzips its man pages.

> Cheers,
> Nicholas

Mark Blackburn