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

Charles Wilson
Tue May 12 01:51:00 GMT 2009

Well, whatever we have now is incredibly fragile. (There's a reason this
message is here, rather than cygwin@. Be patient...)

I just did an installation using the latest 1.7 (2.621) setup.exe under
windows XP (e.g. no Vista headaches) on a newly imaged machine. I did it
as a domain user that is a member of Local Administrators.  Thus: no
registry entries to worry about, no upgrade issues.  The only slight
wrinkle is that %HOMEDRIVE%%HOMEPATH% is set to my domain user home
directory -- so there are a few pre-existing ~/.files.

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/ line 4: cd: /usr/bin: No such file or
2009/05/11 14:56:38 running: C:\cygwin-1.7\bin\bash.exe -c
failed to link /usr/bin/automake -> /etc/alternatives/automake: No such
file or directory
failed to link /usr/bin/aclocal -> /etc/alternatives/aclocal: No such
file or directory
2009/05/11 14:56:39 abnormal exit: exit code=2
2009/05/11 14:56:39 running: C:\cygwin-1.7\bin\bash.exe -c
failed to read link /usr/bin/automake: No such file or directory
failed to link /usr/bin/automake -> /etc/alternatives/automake: No such
file or directory
failed to link /usr/bin/aclocal -> /etc/alternatives/aclocal: No such
file or directory
2009/05/11 14:56:40 abnormal exit: exit code=2

What's even more fun is this:

C:\cygwin-1.7>dir /a
 Volume in drive C is Local Disk
 Volume Serial Number is ECCD-A6A7

 Directory of C:\cygwin-1.7

05/11/2009  03:02 PM    <DIR>          .
05/11/2009  03:02 PM    <DIR>          ..
05/11/2009  02:56 PM                82 autoconf
05/11/2009  02:56 PM                82 autoheader
05/11/2009  02:56 PM                82 autom4te
05/11/2009  02:56 PM                82 autoreconf
05/11/2009  02:56 PM                82 autoscan
05/11/2009  02:56 PM                82 autoupdate
05/11/2009  02:55 PM    <DIR>          bin
05/11/2009  02:56 PM    <DIR>          cygdrive
05/11/2009  03:02 PM                61 Cygwin.bat
05/11/2009  03:02 PM             7,022 Cygwin.ico
05/11/2009  02:56 PM    <DIR>          dev
05/11/2009  02:58 PM    <DIR>          etc
05/11/2009  02:48 PM    <DIR>          home
05/11/2009  02:56 PM                82 ifnames
05/11/2009  02:55 PM    <DIR>          lib
05/11/2009  02:57 PM                38 libXpm.a
05/11/2009  02:57 PM                46 libXpm.dll.a
05/11/2009  02:57 PM                40
05/11/2009  02:49 PM    <DIR>          opt
05/11/2009  02:54 PM    <DIR>          sbin
05/11/2009  02:56 PM    <DIR>          tmp
05/11/2009  02:57 PM    <DIR>          usr
05/11/2009  02:52 PM    <DIR>          var
              12 File(s)          7,781 bytes
              13 Dir(s)   7,335,231,488 bytes free

That is, the target links ended up in /, not /bin OR /etc/alternatives
(there is no physical usr/bin).  That's not right...

So, my two cents is: I think 

(a) / should always be inferred from the location of cygwin1.dll -- that
is, "RO" mount location.
(b) downside: if somebody has multiple installations (boo! bad! hissss!)
then their mount structure depends on which cygwin1.dll is used. BUT --
that's already the case if you find /etc/fstab by inference from
(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
(e) thus, with regards to /usr/bin and /usr/lib, a user doesn't actually
NEED entries in /etc/fstab for them
(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).

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

Only if you want to override the /usr/bin and/or usr/lib entries would
you add them to your /etc/fstab. (Again, I think I agree with cgf about
/ being a un-changeable mount; otherwise you get into weird loops with
locating /etc/fstab. 'Course, if somebody explicitly mounts /etc
someplace wierd, you have those anyway.)

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 the postinstall scripts could at least get a normal initial
mount structure.


More information about the Cygwin-developers mailing list