This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: More: [1.7] packaging problem? Both /usr/bin/ and /usr/lib/ are non-empty


Corinna Vinschen wrote:
>On May 12 09:51, Charles Wilson wrote:
>> 2009/05/11 14:55:58 running: C:\cygwin-1.7\bin\bash.exe -c
>> /etc/postinstall/000-cygwin-post-install.sh
>> Huh?  No /etc/fstab file in \??\C:\cygwin-1.7\etc\fstab.d\cwilso11? 
>> Using default root and cygdrive prefix...
>
> See this message?  That means, at the time 000-cygwin-post-install.sh
> was called the Cygwin DLL didn't find an fstab file.

Sortof. Part of 000-cygwin-post-install.sh's JOB is to create that file
-- and it did so.  So the file exists for the rest of the postinstall
scripts. However, I wonder if there is a caching problem or something --
sure, it was created, but doesn't get used until the next time
cygwin1.dll is loaded into memory?

>> 2009/05/11 14:56:07 running: C:\cygwin-1.7\bin\bash.exe -c
>> /etc/postinstall/passwd-grp.sh
>
> No such "Huh?" message anymore.  So at this point the /etc/fstab file
> already exists.

Sure, but there's still SOME issue with the mount path, because:

2009/05/11 14:56:37 running: C:\cygwin-1.7\bin\bash.exe -c
/etc/postinstall/autoconf.sh
/cygdrive/h/.bashrc
/etc/postinstall/autoconf.sh: line 4: cd: /usr/bin: No such file or
directory

Now, this is interesting.  /etc/postinstall/autoconf.sh looks like this:

------------%<-------------------
bindir=/usr/bin
wrapper=/usr/share/autotools/ac-wrapper.sh

cd ${bindir}

for prog in autoconf autoheader autom4te autoreconf autoscan autoupdate
ifnames
do
	rm -f ${prog}
	ln -sfn ${wrapper} ${prog}
done
------------>%-------------------

That's right: NO shebang line. (I don't remember deliberately ommitting
that. I'll check what's up with that when I get home).  I wonder if all
of the failing postinstall scripts have a similar "mistake"...no,
terminfo.sh seems ok (except it is missing the usual space between '#!'
and '/bin/sh').  Also, the error is in a () subshell?

2009/05/11 14:56:28 running: C:\cygwin-1.7\bin\bash.exe -c
/etc/postinstall/terminfo.sh
/cygdrive/h/.bashrc
/etc/postinstall/terminfo.sh: line 9: cd: /usr/lib: No such file or
directory

------------%<-------------------
#!/bin/sh
# This script will create a symbolic link for old curses apps
# with a hardcoded TERMINFO search path. Also, ensure that all
# database files are readable.
prefix=/usr
terminfodir=${prefix}/share/terminfo
libdir=${prefix}/lib

(cd ${libdir} && rm -f terminfo && ln -fs ${terminfodir} terminfo)

for d in ${terminfodir}/* ; do
	if [ -d ${d} ]; then
		(cd $d && chmod 644 *)
		chmod 755 ${d}
	fi
done
chmod 755 ${terminfodir}

for f in ${prefix}/share/tabset/* ; do
	chmod 644 $f
done
chmod 755 ${prefix}/share/tabset
------------>%-------------------

Hmmm...more thoughts, below...

>> /cygdrive/h/.bashrc
>
> But I don't get what this .bashrc pathname is doing here every time.

That's just my ~/.dotfiles being chatty.  However, I wonder if
postinstall scripts should read ~/.dotfiles at all.  When bash is used
as sh, it doesn't read ~/.stuff.  However, notwithstanding autoconf.sh
above, many of my package's postinstall scripts make use of bashisms, so
I put /bin/bash in the #! line.  It's probably not a good idea for setup
itself to invoke the post/pre scripts using interpreter-specific flags
like -norc because some postinstall scripts might be in other
languages...Do we have a policy about this?  Should I use '#! /bin/bash
-norc' instead?


Back on topic: it's interesting, but the following "core" postinstalls
don't happen until after a number of other, failed, postinstalls. I
would have thought these needed to happen fairly early:

/etc/postinstall/base-files-profile.sh
/etc/postinstall/base-files-mketc.sh [*]

However, even after those two run, I still got postinstall failures
whenever any attempt to explicitly access /usr/bin or /usr/lib was made.
 However, as I said earlier, I think your proposed patch will avoid the
problems I saw...



[*] Should these be fixed, to avoid:

cygwin warning:
  MS-DOS style path detected: C:\WINDOWS\system32\drivers\etc
  Preferred POSIX equivalent is:
  /cygdrive/c/WINDOWS/system32/drivers/etc
  CYGWIN environment variable option "nodosfilewarning" turns off this
  warning.
  Consult the user's guide for more details about POSIX paths:
    http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
`/etc/hosts' -> `C:\\WINDOWS\\system32\\drivers\\etc\\hosts'
`/etc/protocols' -> `C:\\WINDOWS\\system32\\drivers\\etc\\protocol'
`/etc/services' -> `C:\\WINDOWS\\system32\\drivers\\etc\\services'
`/etc/networks' -> `C:\\WINDOWS\\system32\\drivers\\etc\\networks'

Or is using the win32 paths deliberate, because folks might change their
/cygdrive option?


--
Chuck


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]