Re: Dependency issues in setup.ini.

[Jon Turney <jon.turney@dronecode.org.uk>]

On 29/09/2017 21:16, Sam Edge (Cygwin) wrote:
> Hi all.
> 
> 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.
> 
> 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!

Cycles in the dependency graph are unfortunately a real thing (although 
all cycles which exist may not be correct or unavoidable)

cygwin-debuginfo depending on itself is simply a bug in cygport [1], as 
it makes all debuginfo packages unconditionally depend on cygwin-debuginfo

calm permits this as a historical exception, any other package with a 
self-dependency should be rejected.

[1] 
https://github.com/cygwinports/cygport/commit/65cc501f3bea06bcd69326649646568fa5a94092

> 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'?

Again, this is because of historical reasons.

For reasons lost in the mists of time, packaging used to suppress any 
dependency on 'cygwin' from requires: in the setup.hint, and then upset 
would add it back for every single package in setup.ini.

Nowadays, we treat the 'cygwin' dependency the same as any other (i.e. 
any package containing an exe or dll linked to the cygwin DLL should 
have a 'cygwin' dependency)

I believe the maintainer of mintty is still using an old version of 
cygport, which has the historical behaviour, hence this dependency is 
missing.

Practically, this shouldn't cause problems, as the cygwin package is in 
the base category, and so should always be present.

> Is this a known issue or should I report in more detail?

Specific problems should be reported to the cygwin-apps list.


--
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