Re: Dependency issues in setup.ini.

[Sam Edge <sam.edge@gmx.com>]

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