From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 113054 invoked by alias); 20 Oct 2017 18:35:03 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 113044 invoked by uid 89); 20 Oct 2017 18:35:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=urgently, triplets, *that*, *need* X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 20 Oct 2017 18:35:01 +0000 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 87C9EC001CD5 for ; Fri, 20 Oct 2017 18:35:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 87C9EC001CD5 Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=eblake@redhat.com Received: from [10.10.121.90] (ovpn-121-90.rdu2.redhat.com [10.10.121.90]) by smtp.corp.redhat.com (Postfix) with ESMTP id 999F55C3FA for ; Fri, 20 Oct 2017 18:34:59 +0000 (UTC) Subject: Re: Which is it -pc- or -unknown- To: cygwin@cygwin.com References: <59e7e340.e9099d0a.ecab9.127a@mx.google.com> <5e3588d9-d0a6-4181-54aa-56afa5082eab@gmail.com> <10f91c20-d6d0-0dc4-cd2e-f71b2489defd@cygwin.com> <193B1E2F-25B2-4C44-BC27-ADD19DD8CD43@solidrocksystems.com> <59c46d01-832a-357d-53b3-7cc8a7c26f1b@gmail.com> <45b5c7da-e802-ae5f-9692-a9caf94fcda7@cygwin.com> <2e67e7e4-f689-164e-da78-712f60490e9b@gmail.com> <07e896be-05ce-1c21-da25-c66487684bc0@cygwin.com> <0621b067-5960-80d6-5666-4d2248cbd7cf@gmail.com> From: Eric Blake Openpgp: url=http://people.redhat.com/eblake/eblake.gpg Message-ID: <80bdecd3-53b5-1c58-da01-c31348774b0d@redhat.com> Date: Fri, 20 Oct 2017 18:35:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <0621b067-5960-80d6-5666-4d2248cbd7cf@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KKaHWHHVcQCVXw9rgCEqaoBFlCgOTWAeV" X-IsSubscribed: yes X-SW-Source: 2017-10/txt/msg00247.txt.bz2 --KKaHWHHVcQCVXw9rgCEqaoBFlCgOTWAeV Content-Type: multipart/mixed; boundary="N2F8xboQV1RMdaIHMPvOTTWl72j73AG7H"; protected-headers="v1" From: Eric Blake To: cygwin@cygwin.com Message-ID: <80bdecd3-53b5-1c58-da01-c31348774b0d@redhat.com> Subject: Re: Which is it -pc- or -unknown- References: <59e7e340.e9099d0a.ecab9.127a@mx.google.com> <5e3588d9-d0a6-4181-54aa-56afa5082eab@gmail.com> <10f91c20-d6d0-0dc4-cd2e-f71b2489defd@cygwin.com> <193B1E2F-25B2-4C44-BC27-ADD19DD8CD43@solidrocksystems.com> <59c46d01-832a-357d-53b3-7cc8a7c26f1b@gmail.com> <45b5c7da-e802-ae5f-9692-a9caf94fcda7@cygwin.com> <2e67e7e4-f689-164e-da78-712f60490e9b@gmail.com> <07e896be-05ce-1c21-da25-c66487684bc0@cygwin.com> <0621b067-5960-80d6-5666-4d2248cbd7cf@gmail.com> In-Reply-To: <0621b067-5960-80d6-5666-4d2248cbd7cf@gmail.com> --N2F8xboQV1RMdaIHMPvOTTWl72j73AG7H Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Content-length: 2991 On 10/20/2017 11:11 AM, cyg Simple wrote: I may regret joining this thread, but here goes. >> Your assumption is that the default and chosen triplets must/should be >> one and the same.=20=20 >=20 > No, I assume no such thing. >=20 >> They are not, they need not be, and we are far from >> being alone in this regard. Once you accept *that*, then the rest of >> this will make sense. Further insistence that they should be is >> counter-productive at this point. >=20 > You still skirt a reasoning for it to be so. They don't need to be but > why aren't they? Because Cygwin is not the only platform where there is this discrepancy. Having a different guess from the chosen triplet is nothing unique to Cygwin, and therefore, downstream Cygwin need not make any effort to change things. Our reasoning for them to be different can thus be termed "inertia", if you'd like. But it's not a bug, because it doesn't break correct usage, and therefore it does not urgently need to be changed, certainly not with a downstream-only patch. > You've failed to answer the question by assuming I > need to be educated on how it is and refusing to give me a reason of why > it is. I know that I can specify something other than the default. I > don't know why the default is not the same as the chosen. You keep > failing to answer that question. Why does it *need* to stay -unknown- > instead of -pc-? No one says the default NEEDs to stay -unknown-, but the point we're making is that no one has yet provided proof of why it CANNOT stay -unknown-, and that absent any proof for a reason to change, it's better to leave well enough alone. You are more than welcome to propose a patch to upstream config.guess that provides a different default (config.guess is Free Software, after all - as long as you abide by the license terms, you can write and post any patch you like, whether or not we agree with it; but in turn, you have to be prepared that upstream may reject your patch which leaves you with carrying your patch in your personal downstream only); but be aware that your patch may go nowhere upstream. Part of that is that upstream already knows about MULTIPLE platforms where the default string guesses differently than the chosen triple (so Cygwin is not special in that regards), and part of that is that upstream tends to prefer deferring to the developers of a given platform where that is practical, and this thread on the Cygwin list is a good case where the developers of Cygwin have stated that such a patch is not necessary (it might not be harmful, but it is not necessary). Or, if upstream does, for some reason, agree with your patch, it still is not something so urgent that we would backport it downstream any faster than normal propagation of other upstream packages slowly picking up newer config.guess as they release new tarballs. --=20 Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org --N2F8xboQV1RMdaIHMPvOTTWl72j73AG7H-- --KKaHWHHVcQCVXw9rgCEqaoBFlCgOTWAeV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" Content-length: 619 -----BEGIN PGP SIGNATURE----- Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEzBAEBCAAdFiEEccLMIrHEYCkn0vOqp6FrSiUnQ2oFAlnqQdIACgkQp6FrSiUn Q2pgfwf7Bptghhlhr+zICiNBbvN14L1n8dIZ+mMIw8ZQIqpIWckJeqrmX+VobP5/ pdgaKsOuXg/e1tzBSsc36TUyYj/IeXsewQE3xI3X2Dr4mZAFwQjO3aOSt0ThFstu +SReSxZK4BOKJr2SEbioPqUxwE08HrV+WspjlCO8GN0xOsnvDtaCSWHNGkMPSnT8 R8XfuosbByuymcdCVPlwk0XQx4KqwZK6HKZpuiX63yR3kBtmd4ImzBfeuaW0RO6Z DwamAVIr3uQm2DA4vzPuouLBh6IKBi5iYBLao3lNf9TBNVhoXvnGo5uazlCwASnl 5qrAfYJ1KK8PxiyIlHF8VcmPIpdYcA== =KPg4 -----END PGP SIGNATURE----- --KKaHWHHVcQCVXw9rgCEqaoBFlCgOTWAeV--