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


On May 12 12:58, Charles Wilson wrote:
> 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?

Right, but since all postinstall scripts run sequentially with no other
cygwin process in memory, the initialization including reading fstab
files is done for each bash call.

> >> 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:
> [...]
> 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

Nevertheless it has been run as script.  That's quite interesting
because...

> 2009/05/11 14:56:28 running: C:\cygwin-1.7\bin\bash.exe -c
> /etc/postinstall/terminfo.sh

...isn't that wrong?  bash is called from setup with a *script* as
parameter, not with a *command*.  Shouldn't that be `bash foo.sh',
rather than `bash -c foo.sh'?  

> /cygdrive/h/.bashrc
> /etc/postinstall/terminfo.sh: line 9: cd: /usr/lib: No such file or
> directory
>[...]
> 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

And I'm really wondering if your .dotfiles script isn't the problem
here.  Why is it read anyway?  Do you have a $HOME in your Windows
environment?  After all, $HOMEDRIVE$HOMEDIR isn't utilized anymore
to generate a $HOME in Cygwin.

> 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?

Shouldn't setup better use the --norc option?

> 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 [*]

I don't see that these are necessary for the postinstall scripts to run.
Except for /etc/fstab, /etc/passwd and /etc/group, there are no other
files in /etc/ essential for Cygwin.  And the postinstall scripts should
be self-sufficient anyway.

> 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...

I suggest to remove the script from your homedir and retry.  This looks
suspicious and, as I said, I didn't have that problem.

Just don't switch on casesensitivity in the registry!  I just found a
bug in my setup patches from yesterday which break setup on such
systems.  When we figured out how to call bash (-c? --norc?) from
setup, I'll upload a new setup ASAP.

> [*] 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?

Yes, using win32 paths was deliberate, afair.  The warning doesn't
really matter.  Forward slashes would be nice, but they aren't
essential.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat


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