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

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On May 11 21:51, Charles Wilson wrote:
> The postinstall scripts were extremely borked. Anything that used
> alternatives got very confused:
> 
> 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

In the current state of the 1.7 distro, this could only happen if
/etc/fstab hasn't been created right at the start of the postinstall.
That is, base-cygwin ran before any other postinstall script.  In theory
that should never happen because setup 2.621 runs base-cygwin and then
base-passwd explicitely before running any other postinstall stuff.

Did you examine setup.log.full at the point where the postinstall
starts?  What's the package order?  Does
C:\cygwin-1.7\bin\bash.exe -c /etc/postinstall/000-cygwin-post-install.sh
run first?  Any error messages?

The problem is, I can't reproduce this.  When I do a fresh install from
scratch (just done for testing, no cygwin dir, no registry keys), and
the only stuff I install apart from the "Base" category are automake,
autoconf, binutils, gcc, gdb, and make, then everything works as
expected.  I get a /etc/fstab file containing /usr/bin and /usr/lib
entries and the alternatives symlinks are in /etc/alternatives where
they belong.  There's nothing unusual in setup.log.full and the root dir
looks as it's supposed to look.

> So, my two cents is: I think 
> 
> (a) / should always be inferred from the location of cygwin1.dll -- that
> is, "RO" mount location.

Or Chris' "force" option for / which is almost the same.

> (b) downside: if somebody has multiple installations (boo! bad! hissss!)

*shrug*

> (c) usr/bin should be `/bin/cygpath -w /bin` (where / is as above)
> automagically, even in the absence of any fstab entries at all
> (d) ditto usr/lib -> /lib

Did you see my patch in
http://cygwin.com/ml/cygwin-developers/2009-05/msg00030.html?

If no /usr/bin or /usr/lib entries have been read, it creates /usr/bin
and /usr/lib entries after reading fstab by using the native path of /
and appending /bin and /lib.

> (e) thus, with regards to /usr/bin and /usr/lib, a user doesn't actually
> NEED entries in /etc/fstab for them

Exactly.  That would also ease the package dependency problem.

> (f) These last two don't NEED to be RO. But they should at least have
> sensible defaults in the absense of any /etc/fstab at all (as seems NOT
> to be the case for a virgin install at present).

See above.

> This means the "default" installed /etc/fstab would look like this:
> 
> -----------%<------------
> # some comments and stuff
> ----------->%------------
> 
> and is therefore no different that the (intra-initial-installation) case
> on a clean system, thus ensuring that initial installs don't go off the
> rails.

Right.  If Cygwin can create its own /usr/bin and /usr/lib entries,
the 000-cygwin-post-install.sh script would simply create commented
out fstab entries.

And it would ignore any values of /usr/bin and /usr/lib read from
old 1.5 registry entries when creating /etc/fstab.

> The advantage of something like above, is that at the very least, virgin
> installs (e.g a user's first experience with cygwin!) might actually
> work, and t

-v? ;)


Corinna

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