curl calm issue

[Brian Inglis]

On 2020-12-01 08:34, Jon Turney wrote:
> On 01/12/2020 01:06, Brian Inglis wrote:
>> On 2020-11-30 17:09, cygwin-apps-rDBXBDvO6BXQT0dZR+AlfA@public.gmane.org wrote:
>>> WARNING: homepage:https://curl.haxx.se/ permanently redirects to 
>>> https://curl.se/
>>> ERROR: install packages from source package 'curl' have non-unique current 
>>> versions 7.73.0-1 (curl-debuginfo), 7.73.0-2 (3 others)
>>> ERROR: error while validating merged x86_64 packages for Brian Inglis
>>> SUMMARY: 1 WARNING(s), 2 ERROR(s)
> 
> I've added an exception for this package, and set the upload to be retried.

Thanks Jon

I will leave debug enabled in the mingw packages as they are devel, so please 
ignore those release 2, I will leave them at release 1.

>> The issue is that previous releases were always generated with debuginfo,
>> but the latest release also changes debug behaviour to strictly check SSL 
>> protocol, causing execution issues with users and downstreams. >>
>> I would like to generate the updated release without the behaviour change
>> and that appears to also eliminate debuginfo generation. >>
>> If I need to generate release -2 without debuginfo, how do I avoid this
>> issue? >
> Alternatively, you could have added lines to the .cygport to explicitly
> create an empty curl-debuginfo package (or make it obsolete, but that seems 
> contraindicated if the package is coming back in future versions).
Achim seems to think in another reply that I would be better just leaving the 
package as it was, as that will be future upstream behaviour, which was why I 
was asking the questions.

So I could:

* leave the new release as is, with previous behaviour but without debuginfo, 
which may make it difficult for library developers;
* create a newer release the same as release 1 with the new behaviour and 
debuginfo;
* create a newer release to patch out the new behaviour which will become 
default in future, just for this release, and otherwise generate a debug release 
similar to release 1;
* roll back release 2?

Alternate opinions from or agreement with Achim's?

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]