This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]