This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: More: [1.7] packaging problem? Both /usr/bin/ and /usr/lib/ are non-empty
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/