From: Andrey Repin <anrdaemon@yandex.ru>
To: Doug Henderson <djndnbvg@gmail.com>, cygwin@cygwin.com
Subject: Re: Setup shows errors from gnuplot-base.dash and python38-devel.sh
Date: Fri, 16 Jul 2021 06:59:46 +0300 [thread overview]
Message-ID: <806627264.20210716065946@yandex.ru> (raw)
In-Reply-To: <CAJ1FpuPt2Aa9JzYmoO2TmB31JnonGi9xtSkxrh7pgUjvvrWndw@mail.gmail.com>
Greetings, Doug Henderson!
>> >>> When I do that in an elevated shell:
>> >>>
>> >>> $ cd /etc/postinstall/
>> >>>
>> >>> $ cat gnuplot-base.dash
>> >>> /usr/sbin/alternatives --install /usr/bin/gnuplot gnuplot
>> >>> /usr/bin/gnuplot-base.exe 10
>> >>>
>> >>> $ . gnuplot-base.dash
>> >>> failed to read link /usr/bin/gnuplot: No such file or directory
>> >>> failed to link /usr/bin/gnuplot -> /etc/alternatives/gnuplot: No such
>> >>> file or directory
>> >>
>> >> Something seems to be confusing 'alternatives'. Can you show a listing of
>> >> /etc/alternatives?
>> >
>> > $ cd /etc/alternatives/
>> >
>> > $ ls -l
>> > total 2.0K
>> > lrwxrwxrwx 1 Admin None 35 Oct 3 2017 automake-doc ->
>> > /usr/share/info/automake1.9.info.gz
>> > lrwxrwxrwx 1 Admin None 19 Jun 16 17:48 lua -> /usr/bin/lua5.3.exe*
>> > lrwxrwxrwx 1 Admin None 31 Jun 16 17:48 lua.1.gz ->
>> > /usr/share/man/man1/lua5.3.1.gz
>> > lrwxrwxrwx 1 Admin None 20 Jun 16 17:48 luac -> /usr/bin/luac5.3.exe*
>> > lrwxrwxrwx 1 Admin None 32 Jun 16 17:48 luac.1.gz ->
>> > /usr/share/man/man1/luac5.3.1.gz
>> > lrwxrwxrwx 1 Admin None 15 Jun 5 08:46 pip3 -> /usr/bin/pip3.8*
>> > lrwxrwxrwx 1 Admin None 22 Jun 16 07:34 python -> /usr/bin/python3.8.exe*
>> > -rw-r--r-- 1 Admin None 163 Apr 4 2013 README
>>
>> This shows that alternatives worked in June. Have you changed anything since
>> then that might be related to symlinks (e.g., the CYGWIN environment variable)?
>>
>> Here are a few other things you could try:
>>
>> 1. Attach cygcheck output as requested in https://cygwin.com/problems.html
>>
>> 2. Add --verbose to the alternatives call.
>>
>> 3. Run the alternatives call under strace and look for errors involving
>> symlinks. Or post the output somewhere so that we can look at it.
> Now using setup-x86_64.exe version 2.909 (64 bit)
> Postinstall script errors:
> Package: _/Unknown package
> gnuplot-base.dash exit code 2
> python38-devel.sh exit code 2
> Here's what I did in an elevated shell.
> $ cd /etc/alternatives
> $ cat /etc/postinstall/gnuplot-base.dash
> /usr/sbin/alternatives --install /usr/bin/gnuplot gnuplot
> /usr/bin/gnuplot-base.exe 10
> $ /usr/sbin/alternatives --verbose --install /usr/bin/gnuplot gnuplot
> /usr/bin/gnuplot-base.exe 10
> reading /var/lib/alternatives/gnuplot
> failed to read link /usr/bin/gnuplot: No such file or directory
> failed to link /usr/bin/gnuplot -> /etc/alternatives/gnuplot: No such
> file or directory
> $ echo $CYGWIN
> winsymlinks:nativestrict
> *** changed system environment
> $ echo $CYGWIN
> winsymlinks:native
> $ /usr/sbin/alternatives --verbose --install /usr/bin/gnuplot gnuplot
> /usr/bin/gnuplot-base.exe 10
> reading /var/lib/alternatives/gnuplot
> *** Success
> Alternatives does not work correctly when CYGWIN=nativestrict. Perhaps
> it is trying to create a link before the link target exists. Unlike
> Linux, Windows does not allow creating symbolic links to non-existent
> targets.
> The /etc/postinstall/python38-devel.sh also works now.
> Also after changing env back to CYGWIN=winsymlinks:nativestrict the
> erroring postinstall scripts continue to work. This supports my
> suspicion that /usr/sbin/alternatives is trying to create a symbolic
> link to a target before it creates the target when it is performing
> the first install for an alternative. On subsequent runs, the target
> already exists.
> I have unattached the output from cygcheck, as I do not believe it
> will help now.
> Am I the only person that uses "CYGWIN=winsymlinks:nativestrict" ???
$ echo "$CYGWIN"
wincmdln winsymlinks:nativestrict glob:ignorecase
> Sorry for all the bother. My aging brain forgot how I made
> alternatives work for Lua last month.
I've stumbled upon the same problem earlier.
alternatives tries to create a link pointing to a nonexistent file. Which is
valid in Linux, but impossible in Windows.
IMO, this is a logical fallacy and should not be attempted, making it an
upstream bug.
--
With best regards,
Andrey Repin
Friday, July 16, 2021 6:56:55
Sorry for my terrible english...
prev parent reply other threads:[~2021-07-16 4:05 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-14 16:59 Doug Henderson
2021-07-14 19:02 ` Achim Gratz
2021-07-14 19:59 ` Marco Atzeri
2021-07-14 21:08 ` Doug Henderson
2021-07-14 22:31 ` Ken Brown
2021-07-15 1:20 ` Doug Henderson
2021-07-15 11:57 ` Ken Brown
2021-07-15 16:04 ` Doug Henderson
2021-07-15 16:18 ` ASSI
2021-07-16 3:59 ` Andrey Repin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=806627264.20210716065946@yandex.ru \
--to=anrdaemon@yandex.ru \
--cc=cygwin@cygwin.com \
--cc=djndnbvg@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).