This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: Dependency issues in setup.ini.
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