From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 63565 invoked by alias); 30 Sep 2017 10:57:15 -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 63553 invoked by uid 89); 30 Sep 2017 10:57:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=esteemed, andrey, Andrey, naive X-HELO: mout.gmx.net Received: from mout.gmx.net (HELO mout.gmx.net) (212.227.17.20) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 30 Sep 2017 10:57:12 +0000 Received: from [192.168.15.105] ([92.20.186.130]) by mail.gmx.com (mrgmx103 [212.227.17.174]) with ESMTPSA (Nemesis) id 0MFctN-1eA1ho13bx-00EdwP for ; Sat, 30 Sep 2017 12:57:09 +0200 Subject: Re: Dependency issues in setup.ini. To: cygwin@cygwin.com References: <505405e4-5a2f-8d6b-f012-404bd7d69009@gmx.com> <216159991.20170930120008@yandex.ru> From: Sam Edge Message-ID: <171d601b-59c2-f186-5213-12c6b6f493cd@gmx.com> Date: Sat, 30 Sep 2017 11:35:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <216159991.20170930120008@yandex.ru> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-UI-Out-Filterresults: notjunk:1;V01:K0:EoUhD7BsJAY=:hecwB++4cQGXLWz3zh5LAd KG4j94XUrmfTNS5xlS/iV1JOwLFFE6IEdnOZauARzeD2Nagu2lyTXcqFUhQ+5igP2R0zcBsrz OLlgYhfnujI1kZI2ULZY1xh894wEbOvgjcn4J6O9bRvUbaCx/Kny6yjwlKvuQfN6nYqk4la+V iNCVj3+fn9g1NYH6NCxB2c7VXs/YCTJHR+GCCpxjy03UFob4/q2p+29A093Djg0A0Bd+l1xP5 6mfKERBbyyxu4x63dAMdiRMzQoBC+qrtD7kyGsfHSgT4TUWX8MYaSRwGstFwFAarxrA9wzwzB 32mkL7FUMASz8nE42eMTXv43uywnVQumS3xtzSFo9wt0fQd8jOofrgEQZgGJBQOYgOcw7364c imPgPRhX4JUlyh0XmO1QfSisD28pXJau2/9sQu7J0BoDdR8++30whMoCU1anRsM/7QFxop1Zg TS88+vnZlfQiS2sKn115ihUfh8uKZya0lCk7Q3QaJ5A+ldl5aYK2/t5tRrDBUNBhT5jDkMG8u xe7MA9lsWXXRoYiKkG+xb6HJH3A+Lj7lu/PwrmL4YqdGVNsHulFp38huv+fB1Sqr+3lB/u5ka Iu02SssXjnUcRVO/8g9oaULfPqT4lB10QzEoCyoqYTZGkUZnzsUHTTA1uHuLi2UvxQX8wxXbR fDDBrGiYiVGPcWio6Grr8lADtF/gsugMPSPK3AOBdQT6/ca3EQjEEaCxx8Mp26EwZ5OPsKxf4 eCOwFvquyrQRuCmzRsiEKzevS1SRgUXpCdtegPdf6Vk3PO5CaZNUPydDdPA/sCBLa85LGokgJ dM5JPQDw2pyAYGXBD2cOH1lrQNhH917B6/3I0nxEnV6sY3CEXw= X-IsSubscribed: yes X-SW-Source: 2017-09/txt/msg00311.txt.bz2 Hi Andrey. Nice to be back in a thread with such esteemed folk. ;-) On 30/09/2017 10:00, Andrey Repin wrote: > Greetings, Sam Edge (Cygwin)! > >> I've been developing a Python package that can interrogate and >> manipulate local package caches (the directories where setupXXX.exe >> keeps its downloads) and installation databases (from Cygwin >> /etc/setup/installed.db files) with a mind to pruning, merging and >> reporting in the spiript of Michael A. Chase's 'clean_setup' utility but >> as a scriptable tool set rather than a stand-alone utility. > I'm eager to see the fruits of your labor. Don't hold your breath! :-) I'm doing it partly to teach myself the subtleties of Python classes and I've not yet got to the process of turning it into an installable import module. Also, its re-based parser is still a bit naive. It works okay with the current setup.ini but it has vulnerabilities I'd like to eliminate.(Hopefully I'll have something I won't be embarrassed to share before Yuletide.) >> It's not production ready yet but it's already flagged up some issues. >> For example we have lots of dependency loops in the 'requires' fields in >> setup.ini - even to the point that some packages depend upon themselves! > Dependency upon itself is curious, but other than that, this is a normal > situation for a package manager. Some packages are split for easier > maintenance of each, but are interlocked in their typical usage pattern. Ah, okay. Fair enough. It can be difficult to keep things layered purely up & down I know. Although often it can be resolved by introducing a third module that acts as the muxer between the other two to avoid cross API dependencies. But that's a discussion for another mailing list. But I'm also seeing loops deeper that X->Y->X. More like X->Y->Z->W->X. (The self-dependency is cygwin-debuginfo by the way.) >> And also we have some dependency omissions. For example, mintty doesn't >> depend upon anything - it has no requires field. Surely, every binary >> package should depend at least upon 'cygwin'? > While this is "not good", this is also not particularly bad for packages in > base - this group is always installed. Indeed. However, while off label usage of Cygwin is anathema to me but sometimes I wish 'base' wasn't quite so big and have to pare things down a little once installed, e.g. as part of a makefile- and/or Eclipse-based build tree in source code control.(Which was also one of my motivations for the Python stuff.) >> Is this a known issue or should I report in more detail? > Nonetheless, such issues are best kept highlighted, unless it is clearly > seen/documented as intended. > Will try to collate a list as soon as I have a free (as in not too bushed) weekday evening. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple