Ready for test coreutils-5.2.0-1 [again]

[Christopher Faylor]

On Sun, Mar 14, 2004 at 01:18:20PM -0500, Nicholas Wourms wrote:
>>Here's what's changed since my last packaging attempt:
>>
>>1) The following files are deleted from the distribution:
>>usr/bin/uptime.exe
>>usr/bin/kill.exe
>>usr/share/man/man1/uptime.1.gz
>>usr/share/man/man1/kill.1.gz
>>
>>2) Fileutils patches have been included.
>>
>>Package is available at the same location:
>>
>>http://blackburn.homeip.net/cygwin-packages/release/coreutils/coreutils-5.2.0-1-src.tar.bz2 
>>
>>http://blackburn.homeip.net/cygwin-packages/release/coreutils/coreutils-5.2.0-1.tar.bz2 
>
>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.

Joshua Daniel Franklin already mentioned this on Friday.  It's the
standard way of dealing with this.

>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

This would seem to imply that all of these mknetrel fragments are
dealing with that awful lack of POSIX compliance, which is not the case.

>Note that it is easier to just to pass -L/usr/lib -lbinmode to LDFLAGS 
>instead of bothering with printing gcc's search path.

No, actually it's not.  1) Adding -L/usr/lib makes no sense.  2)
-lbinmode doesn't work, anyway.  I added the libraries a while ago
thinking it would make things easier but since nothing in the main
program references anything in libbinmode.a, nothing from libbinmode.a
is loaded.  You do need to either take that fact into account or just
load binmode.o.

It's entirely possible that since coreutils is more modern than fileutils
it does not need binmode.o.  There is no reason to force this unless it
is required.

Anyone want to verify if it is?

cgf