Re: Please try new setup exe's

[Christopher Faylor <cgf-use-the-mailinglist-please at cygwin dot com>]

On Tue, Jul 16, 2013 at 08:50:08PM +0200, Corinna Vinschen wrote:
>On Jul 16 14:18, Christopher Faylor wrote:
>> On Tue, Jul 16, 2013 at 08:09:14PM +0200, Corinna Vinschen wrote:
>> >On Jul 16 11:04, Christopher Faylor wrote:
>> >> On Tue, Jul 16, 2013 at 11:37:17AM +0100, Jon TURNEY wrote:
>> >> >On 16/07/2013 03:08, Christopher Faylor wrote:
>> >> >> On Mon, Jul 15, 2013 at 09:49:12PM -0400, Ken Brown wrote:
>> >> >>> setup-x86_64.exe behaves differently from setup64.exe with respect to 
>> >> >>> source-only packages.  (I don't know which one is "right".)  This is 
>> >> >>> showing up for me because the 64-bit versions of gcc and readline are 
>> >> >>> source-only packages that are (incorrectly?) required by other packages. 
>> >> >>>  setup64.exe seems to ignore these requirements, whereas 
>> >> >>> setup-x86_64.exe wants to install the packages but then reports 
>> >> >>> "Incomplete download".
>> >> >> 
>> >> >> Thanks for trying this.  I doubt that is anything that I introduced.
>> >> >> 
>> >> >> Do you see the same behavior from setup-x86.exe?
>> >> >
>> >> >In x86, readline is the devel package, and so has source and binary tar files.
>> >> >
>> >> >In x86_64, the packaging is different and a libreadline-devel package has been
>> >> >added, so readline is now source only, but has things which depend on it (e.g.
>> >> >gawk, gdb, python) becuase they haven't been updated for this change.
>> >> >
>> >> >It seems setup reports trying to install a package for which it knows no
>> >> >versions with the helpful message "Incomplete download" :-)
>> >> 
>> >> It seems like these issues are being fixed but should we modify setup's
>> >> behavior to be less "helpful"?
>> >> 
>> >> Hmm.  I wonder if upset could also report on these problems as well.
>> >
>> >In upset it be more useful, imho, because we get immediate warning
>> >when the problem occurs.
>> 
>> I can do that but was there a setup regression here?  It sounded like
>> the old setup64.exe doesn't complain about these issues.  Or does it
>> complain now with the lastest packages?
>
>The former setup64 doesn't complain, but I don't think this is a setup
>problem.  Rather, it's a difference between the generated ini files.
>The old setup64.ini was only generated by genini, the new by upset.
>
>For instance, here's the gcc entry generated by genini:
>
>  @ gcc
>  sdesc: "GNU Compiler Collection"
>  ldesc: "The GNU Compiler Collection includes front ends for C, C++,
>  Objective-C, Fortran, Java, Ada, and Go, as well as libraries for these
>  languages (libstdc++, libgcj,...)."
>  category: Devel
>
>And here's the gcc entry as generated by upset:
>
>  @ gcc
>  sdesc: "GNU Compiler Collection"
>  ldesc: "The GNU Compiler Collection includes front ends for C, C++,
>  Objective-C, Fortran, Java, Ada, and Go, as well as libraries for these
>  languages (libstdc++, libgcj,...)."
>  category: Devel
>  version: 4.8.1-1
>  source: x86_64/release/gcc/gcc-4.8.1-1-src.tar.bz2 87070214 eb70273d8a2a555d995b0675980fcc1c
>  [prev]
>  version: 4.8.0-2
>  source: x86_64/release/gcc/gcc-4.8.0-2-src.tar.bz2 86977149 128658603c4daac97e62b4778c22a56d
>
>So in one case the entry doesn't contain any package, in the other
>case we have "source" entries.  With the same input, I bet setup64
>behaves the same as setup-x86_64.
>
>[...time passes, testing...]
>
>yes, when using the new setup.ini with the old setup64.exe, the effect
>is the same.

Thanks for checking.  Sounds like a genini bug.

I've uploaded a new upset which checks for this corner case problem.

cgf