This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: More: [1.7] packaging problem? Both /usr/bin/ and /usr/lib/ are non-empty
- From: "Charles Wilson" <cygwin at cwilson dot fastmail dot fm>
- To: "cygwin-developers at cygwin dot com" <cygwin-developers at cygwin dot com>
- Date: Mon, 11 May 2009 21:51:17 -0400
- Subject: Re: More: [1.7] packaging problem? Both /usr/bin/ and /usr/lib/ are non-empty
- References: <1242049292.17770.ezmlm@cygwin.com>
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/autoconf.sh
/cygdrive/h/.bashrc
/etc/postinstall/autoconf.sh: line 4: cd: /usr/bin: No such file or
directory
2009/05/11 14:56:38 running: C:\cygwin-1.7\bin\bash.exe -c
/etc/postinstall/automake1.4.sh
/cygdrive/h/.bashrc
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
/etc/postinstall/automake1.5.sh
/cygdrive/h/.bashrc
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 libXpm.la
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
dirOf(cygwin1.dll)/../etc.
(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
rails.
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.
--
Chuck