From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) by sourceware.org (Postfix) with ESMTPS id 5775E3858C60 for ; Sat, 2 Oct 2021 05:48:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5775E3858C60 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=SystematicSw.ab.ca Authentication-Results: sourceware.org; spf=none smtp.mailfrom=systematicsw.ab.ca Received: from shw-obgw-4004a.ext.cloudfilter.net ([10.228.9.227]) by cmsmtp with ESMTP id WMGdmphaOczbLWXsPmsmBr; Sat, 02 Oct 2021 05:48:01 +0000 Received: from [192.168.1.105] ([68.147.0.90]) by cmsmtp with ESMTP id WXsPmgZiudCHGWXsPmVVQa; Sat, 02 Oct 2021 05:48:01 +0000 X-Authority-Analysis: v=2.4 cv=SdyUytdu c=1 sm=1 tr=0 ts=6157f291 a=T+ovY1NZ+FAi/xYICV7Bgg==:117 a=T+ovY1NZ+FAi/xYICV7Bgg==:17 a=IkcTkHD0fZMA:10 a=YvF7pgciB9gHa7Y2HakA:9 a=QEXdDO2ut3YA:10 Reply-To: cygwin-apps@cygwin.com To: cygwin-apps@cygwin.com References: <9b1ea563-f5c0-04f2-d117-6f792b6cdb94@SystematicSw.ab.ca> <87tui0jc4x.fsf@Rainer.invalid> From: Brian Inglis Organization: Systematic Software Subject: Re: CI scallywag setup/cygport/autoconf missing autoconf-archive pkg Message-ID: <66c249a2-debb-c0a0-6633-7f1d4e4ad1f1@SystematicSw.ab.ca> Date: Fri, 1 Oct 2021 23:48:00 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <87tui0jc4x.fsf@Rainer.invalid> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-CA Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4xfO5um2DFEIgB+hc7l8MWojjexyNi/VGFCpvIaG98oShSQqd33ErPII+OFgZuWwsQK8Lo/kl2zKrcWkJzl7h4qBAaxwvW3l8um8RhakiAZnQ7de1eA7Lr g4ZC3b9hmftSpzvlAb6oC2cb8GxzHMPBWPG2Qb3pM+FtfVYKSVl3AOuUY1XEADBZeGtpwhk8Tb1X6oCeT+LvH6mKKQ14lwUH+lk= X-Spam-Status: No, score=-1161.5 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: cygwin-apps@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cygwin package maintainer discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Oct 2021 05:48:03 -0000 On 2021-10-01 22:15, Achim Gratz wrote: > Brian Inglis writes: >> As autoconf requires: autoconf2.1 autoconf2.5 bash sed, I believe that >> would be the more appropriate place for an autoconf-archive >> requirement, otherwise cygport would have to require it, which is not >> so obvious. > > No. If a build needs autoconf-archive then require it there. The whole > point of having things in separate packages is that you do not have to > install things you don't need. Neither autottols nor cygport require > this package in any way. See response to Yaakov: the problem is it's just a given in the build systems of the packages that use it, just as is gnulib implicitly, so neither are ever mentioned as requirements or components. You have to trip over the problems, try to find occurences online (which is difficult with packages preinstalled with every Linux or GNU development setup), dig down to find the problem, dig around to find the solution; possibly bounce it off upstream, and reference, pull, or adapt their patch which is to their current master; or if it's a Cygwin environment issue, fix it in cygport; and request that upstream at least mention it in their requirements (for which they may think you, or the Cygwin build setup, may have some deficiencies); or mention that they include a release of something which is really an ongoing creeping unreleased blob: gnulib as of when they last picked it up; or some other pet project of theirs which they just embed in their package, as it worked on their system, and saves them writing a few new lines of code. > Off-tangent: cygport has entirely too many dependencies already which we > can't help with our current package system. I'd love to have a way for > these dependencies not to creep into each build. I'd love to have a way for maintainers not to have to figure out what is missing from the Cygwin build system that upstream package developers just assume everyone has on their GNU, Linux, Debian, Fedora, OpenSuSE or etc. build system! ;^> I admit I am clueless about autotools, open source development, and build systems. I have worked mainly in commercial, corporate environments, with teams of a few dozen to a couple of hundred, sometimes dozens but usually hundreds of support staff, where they want some product fixed or enhanced the next day, provide minimal tools, and don't really care how the job gets done, as long as it is cheap and soon, or at least within their planned timeframe and budget. (But necessarily according to this month's list of approved or required architectures, languages, tools, techniques, methodologies, and project approaches!) ;^> And this month has had me spending most of my free time for Cygwin tripping over issues of only three packages with mysterious issues never encountered or imagined by the upstreams because of their build environments; and that makes me pause from contemplating adopting others, if each could take up a week of my free time to handle each new update. Maintainers can spent their time chasing issues with Cygwin "deficiencies" and digging into the issues, working with upstream developers to track down problems, and asking upstream developers to document things (shock!) which no other downstream has ever requested; or they can release upgraded packages with minimal friction! But I've always felt putting obstacles that can be easily mitigated in the way of getting the good work done with minimal friction is possibly not the best approach that any group should take. [I got an impression that bits of gnulib blobs may be making their way into the more formal packaging of autoconf-archive to avoid GNU autotools maintainers having to blast in random gnulib replacement blobs once in a while and hope that nothing breaks (on their development platform at least).] -- 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.]