Setup shows errors from gnuplot-base.dash and python38-devel.sh

Doug Henderson djndnbvg@gmail.com
Thu Jul 15 16:04:13 GMT 2021


"On Thu, 15 Jul 2021 at 05:59, Ken Brown via Cygwin <cygwin@cygwin.com> wrote:
>
> On 7/14/2021 9:20 PM, Doug Henderson via Cygwin wrote:
> > On Wed, 14 Jul 2021 at 16:33, Ken Brown via Cygwin <cygwin@cygwin.com> wrote:
> >>
> >> On 7/14/2021 5:08 PM, Doug Henderson via Cygwin wrote:
> >>> On Wed, 14 Jul 2021 at 13:03, Achim Gratz <Stromeko@nexgo.de> wrote:
> >>>>
> >>>> Doug Henderson via Cygwin writes:
> >>>>> The first error message occurred when I installed all pending packages
> >>>>> this morning. I hoped to heal the problem by reinstalling the
> >>>>> installed gnuplot packages. Now I get both the messages.
> >>>>
> >>>> If you look in /var7Log/setup.log.full you should be able to see what
> >>>> error messages, if any, were recorded.
> >>>>
> >>>> The gnuplot related script should just set up the current alternative
> >>>> for "gnuplot" to use, but something on your system seems to prevent
> >>>> that from happening.  You can also run the script in sh (you must tell
> >>>> the shell to source it) and should get the same error (most likely).
> >>>
> >>> 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" ???
Sorry for all the bother. My aging brain forgot how I made
alternatives work for Lua last month.

HTH
Doug

-- 
Doug Henderson, Calgary, Alberta, Canada - from gmail.com


More information about the Cygwin mailing list