X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	q=dns; s=default; b=HWHj9pYix0Pswnc4sCta0wDGXKycsmleU5xM/+1ZaSq
	KJRMdc6g5U35QsmT6+ku965ZLcjOG25TlPpUF0rJtqTpgBX7QhOWmvvR7G5eQDKx
	wgRGahXuLwzXHdbM2F/idXXlV4balCNwfstPam1va6hyZiTphHS3pSJ2J4s00YcU
	=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	s=default; bh=LRK8+GDia5Q/QH1AywvOFfkC3Dc=; b=ExOlU4Hu3XOht97S8
	2lRUmlPTvjPuXFa4Rj0eosdfXrdka7ujn7sVCtq3IwUikvEo0LJY9HG34W3uA10x
	k+aYTo5wS8+vS2snAwIXA2a5tyTdZRFGGBRj6rILs0b9IjFGqLcBy0yMfIdMjjTX
	405TWI/XTkZotD6dC7sZtHfTDI=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=0.1 required=5.0 tests=AWL,BAYES_50,RDNS_NONE autolearn=no version=3.3.2
X-HELO:	bureau82.ns.utoronto.ca
Message-ID:	<5277CED7.1000302@cs.utoronto.ca>
Date:	Mon, 04 Nov 2013 11:44:07 -0500
From:	Ryan Johnson <ryan DOT johnson AT cs DOT utoronto DOT ca>
User-Agent:	Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: setup.ini dependency graph?
References:	<526A986D DOT 9040202 AT cwilson DOT fastmail DOT fm> <526B8DF9 DOT 5000004 AT tiscali DOT co DOT uk> <5271000D DOT 7000604 AT cwilson DOT fastmail DOT fm> <52710EC5 DOT 2020403 AT cs DOT utoronto DOT ca> <5277AFEA DOT 9060404 AT cwilson DOT fastmail DOT fm> <20131104160032 DOT GB5526 AT ednor DOT casa DOT cgf DOT cx>
In-Reply-To:	<20131104160032.GB5526@ednor.casa.cgf.cx>
X-IsSubscribed:	yes

On 04/11/2013 11:00 AM, Christopher Faylor wrote:
> On Mon, Nov 04, 2013 at 09:32:10AM -0500, Charles Wilson wrote:
>> On 10/30/2013 9:51 AM, Ryan Johnson wrote:
>>> On 30/10/2013 8:48 AM, Charles Wilson wrote:
>>>> Yeah; even for my stripped-down version, I need to pre-process the
>>>> setup.ini and remove all mentions of cygwin, libstdc++6, libgcc1, etc.
>>>> The ncurses DLLs are also a huge nexus.  (It's probably easier to
>>>> exclude those nodes by mucking with the perl, but...)
>>> Quick question: do you have 1+ known-big-unwanted packages and need to
>>> know who's pulling them in, or are you hoping to take some cut of the
>>> graph that gets as many desirable packages as possible given the space
>>> constraints? The graph-building script here is good for the latter, but
>>> I had the impression you were doing the former; if so, my script might
>>> get you to an answer faster by avoiding information overload.
>> A combination of the two, actually.  I've used both David's script and
>> yours in concert.  In addition, I've modified David's script to color
>> the nodes based on origination, and to exclude or collapse 'Base' and/or
>> 'required-by-Base' packages.
>>
>> I've got a few cleanups, and then I'll share the result.  It's already
>> helped me generate a few re-packaging requests I plan to post over on
>> cygwin-apps...
> Is this packagable?  It sounds pretty interesting.
>
> Would it be crazy to generate this and make it available on the cygwin
> web site?  Or would the dependency graph generation overload
> sourceware.org?
Throwing graphviz at a full cygwin package dependency graph would make a 
pretty effective DoS attack. Smaller graphs are cheaper, but still 
consume non-trivial compute. Given how slowly the online regexp package 
search goes, I'd hesitate to give users more ways to overload the server...

What about calling out to graphviz from setup.exe (if found in %PATH%), 
as a replacement/supplement for the flat list of dependencies it 
currently reports? That would put all processing on the client, and 
limit the "big data" problem, as the graph only contains packages a user 
is currently trying to install.

Alternatively, cygcheck could gain a new -g option to dump subsets of a 
dependency graph, extracted from setup.ini, in some appropriate format 
like .dot:

`cygcheck -D -g python' would emit the graph of packages that python 
depends on
`cygcheck -R -g texlive,xorg-server' would build a braph of packages 
that pull in either of texlive or xorg-server (reverse dependencies)
-D -R -g would follow dependencies in both directions, and -g would be 
shorthand for -D -g; probably -D or -R by itself implies -g.

The actual work could be done by calling out to a scripting language 
that ships with cygwin. Awk would probably be able to, and perl 
certainly could.

/daydreaming

Ryan



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

- Raw text -