This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: Please try new setup exe's
- From: Christopher Faylor <cgf-use-the-mailinglist-please at cygwin dot com>
- To: cygwin-apps at cygwin dot com
- Date: Wed, 17 Jul 2013 14:35:14 -0400
- Subject: Re: Please try new setup exe's
- References: <20130716002025 dot GA7360 at ednor dot casa dot cgf dot cx> <51E4A698 dot 7040308 at cornell dot edu> <20130716020836 dot GA7389 at ednor dot casa dot cgf dot cx> <51E5225D dot 7080004 at dronecode dot org dot uk> <20130716150448 dot GA6319 at ednor dot casa dot cgf dot cx> <20130716180914 dot GQ2712 at calimero dot vinschen dot de> <20130716181823 dot GB3872 at ednor dot casa dot cgf dot cx> <20130716185008 dot GS2712 at calimero dot vinschen dot de> <20130716185922 dot GA4068 at ednor dot casa dot cgf dot cx> <51E6E23E dot 40506 at cwilson dot fastmail dot fm>
- Reply-to: cygwin-apps at cygwin dot com
On Wed, Jul 17, 2013 at 02:28:14PM -0400, Charles Wilson wrote:
>On 7/16/2013 2:59 PM, Christopher Faylor wrote:
>> On Tue, Jul 16, 2013 at 08:50:08PM +0200, Corinna Vinschen wrote:
>>>
>>> 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.
>
>So...genini should generate version/source lines for directories that
>contain only -src packages and no binary.
>
>But, wouldn't that mean that setup[-x86|-x86_64||64] would still
>complain if there were a setup.hint "somewhere" in tree that required:
>the source-only package? I think the answer is yes; so what's the
>solution there? cgf's change to upset to make it complain about the
>situation, in a "Doctor, it hurts when I do this/Then don't do that"
>kind of way?
I just fixed (in theory) the possibility that a (IMO) malformed
setup.ini would cause a problem in setup.exe. It would be really
nice if someone could fix setup.exe too since it definitely shouldn't
be possible to get into the state where the user gets a "Download
incomplete" and requires Ken Brown's insight to figure out why.
Btw, the upset solution was to issue an error and not generate the .ini
file at all.
cgf