This is the mail archive of the
mailing list for the Cygwin project.
Re: Dependency issues in setup.ini.
- From: Jon Turney <jon dot turney at dronecode dot org dot uk>
- To: The Cygwin Mailing List <cygwin at cygwin dot com>
- Cc: "Sam Edge (Cygwin)" <sam dot edge dot cygwin at gmx dot com>
- Date: Mon, 2 Oct 2017 14:25:20 +0100
- Subject: Re: Dependency issues in setup.ini.
- Authentication-results: sourceware.org; auth=none
- References: <firstname.lastname@example.org>
On 29/09/2017 21:16, Sam Edge (Cygwin) wrote:
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 , 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.
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
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
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple