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

[Charles Wilson <cygwin at cwilson dot fastmail dot fm>]

Fergus wrote:
>> Just noticed that after the recent unison upgrade there exists a file
>>     /usr/bin/unison
>> Also just noticed (but this must have occurred a while ago - 30/03/09
>> maybe, the date of a TeX upgrade?) that there now exists a directory
>>     /usr/lib/texmf/
>> with deep non-empty subdirectory structure.
>> Is it the case for [1.7] that both /usr/bin/ and /usr/lib/ should be
>> empty as for [1.5]?
>> Possibly the texmf/ packaging issue has been corrected in subsequent
>> upgrades and so /usr/lib/texmf/ can be deleted without compromising
>> functionality; but I think the appearance of /usr/bin/unison is very new.
>> Fergus
> 
> And again: following the recent upgrade to rxvt-unicode there are now 3
> "real" files in /usr/lib/ being
> 
> C:\>attrib m:\usr\bin\*
> A  S         M:\usr\bin\urxvt
> A  S         M:\usr\bin\urxvtc
> A  S         M:\usr\bin\urxvtd
> 
> (As you perceive, these are all links: in fact to files of the same name
> in /etc/alternatives/. There are identical links in m:\bin\.)

That's very odd. Those files are created by the postinstall script,
which is run by setup.exe in a "real" cygwin shell.  That is, it's just
a bash script that runs

prefix=/usr
bindir=${prefix}/bin
${sbindir}/update-alternatives \
        --install ${bindir}/urxvt   urxvt   ${bindir}/urxvt-X.exe   30 \
        --slave   ${bindir}/urxvtc  urxvtc  ${bindir}/urxvtc-X.exe \
        --slave   ${bindir}/urxvtd  urxvtd  ${bindir}/urxvtd-X.exe

BUT, because it's in a bash shell, it OUGHT to know about all of the
mount points, especially

cygwin-1.7 (cat /etc/fstab):
C:/cygwin-1.7 / some_fs binary 0 0
C:/cygwin-1.7/bin /usr/bin some_fs binary 0 0
C:/cygwin-1.7/lib /usr/lib some_fs binary 0 0

cygwin-1.5 (mount -m):
C:/cygwin-1.7/bin /usr/bin ntfs binary 0 0
C:/cygwin-1.7/lib /usr/lib ntfs binary 0 0
C:/cygwin-1.7 / ntfs binary 0 0

It seems, then, that perhaps there's something wrong with setup's
"setup" of that cygwin environment, before/as it launches the
postinstall scripts ON YOUR MACHINE.

The reason I specify *your machine*, is I can't reproduce this behavior.
In fact, I don't even HAVE a C:\cygwin-1.7\usr\bin directory, so my
symlinks are actually in C:\cygwin-1.7\bin, as they should be.

--
Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/