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
