From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12186 invoked by alias); 30 Sep 2017 11:35:08 -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 12162 invoked by uid 89); 30 Sep 2017 11:35:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.0 required=5.0 tests=BAYES_00,FREEMAIL_FROM,KAM_THEBAT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy=terrible, HX-Priority:Normal, H*F:D*yandex.ru, H*M:yandex X-HELO: forward105j.mail.yandex.net Received: from forward105j.mail.yandex.net (HELO forward105j.mail.yandex.net) (5.45.198.248) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 30 Sep 2017 11:35:04 +0000 Received: from mxback8o.mail.yandex.net (mxback8o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::22]) by forward105j.mail.yandex.net (Yandex) with ESMTP id 18A15184767; Sat, 30 Sep 2017 14:35:02 +0300 (MSK) Received: from smtp1p.mail.yandex.net (smtp1p.mail.yandex.net [2a02:6b8:0:1472:2741:0:8b6:6]) by mxback8o.mail.yandex.net (nwsmtp/Yandex) with ESMTP id ocFX3c4qyv-Z1XCIXQe; Sat, 30 Sep 2017 14:35:02 +0300 Received: by smtp1p.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id RzbEy3bTvb-Z1sqROt8; Sat, 30 Sep 2017 14:35:01 +0300 (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client certificate not present) Authentication-Results: smtp1p.mail.yandex.net; dkim=pass header.i=@yandex.ru Received: from [192.168.1.10] (HELO daemon2.darkdragon.lan) by daemon2 (Office Mail Server 0.8.12 build 08053101) with SMTP; Sat, 30 Sep 2017 11:23:14 -0000 Date: Sat, 30 Sep 2017 11:51:00 -0000 From: Andrey Repin Reply-To: cygwin@cygwin.com Message-ID: <19010162357.20170930142314@yandex.ru> To: Sam Edge , cygwin@cygwin.com Subject: Re: Dependency issues in setup.ini. In-Reply-To: <171d601b-59c2-f186-5213-12c6b6f493cd@gmx.com> References: <505405e4-5a2f-8d6b-f012-404bd7d69009@gmx.com> <216159991.20170930120008@yandex.ru> <171d601b-59c2-f186-5213-12c6b6f493cd@gmx.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-09/txt/msg00312.txt.bz2 Greetings, Sam Edge! >>> 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. More than that, naive assumption of no circular dependency is the most common cause for infinite recursions. > 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. A list indexed by package name is necessary when you resolve package dependencies. Then you always know when to avoid dependency rescans. > (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.) Rational suggestions are always welcome, I suppose. While my own usage of Cygwin is prone to spread thin across all aspects of my daily work, I can see situations, where a much smaller subset of packages (let's name it "core" or something) would be beneficial. I.e. when packaging Cygwin as part of your own application. -- With best regards, Andrey Repin Saturday, September 30, 2017 14:16:20 Sorry for my terrible english... -- 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